Bug 19814 - Batch Check-in function
Summary: Batch Check-in function
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P1 - high new feature with 63 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-14 15:50 UTC by Michal
Modified: 2024-04-17 13:49 UTC (History)
38 users (show)

See Also:
Change sponsored?: Seeking cosponsors
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 Michal 2017-12-14 15:50:53 UTC
Hi,
in Koha exists function named "Batch Check out" but there is no "Batch Check in". A lot of small libraries don't have self-check station. Maybe a good solution would be adding function "Batch Check in"?

Thanks a lot
Regards
Comment 1 Martha Fuerst 2018-01-17 19:30:28 UTC
Seconding the usefulness of such a feature.

-Marti
Comment 2 Laura 2019-07-12 08:29:17 UTC
Hi 

I think this would be an excellent fuction and an obvious one for workflows.
Comment 3 Fiona Borthwick 2019-07-25 13:52:22 UTC
A lot of our customers would welcome this functionality. Considering Koha now offers a batch checkout feature, it would be good to have a batch checkin option.
Comment 4 Rob Corp 2019-08-09 08:23:29 UTC
We'd find this useful too
Comment 5 Christopher Brannon 2019-10-04 22:24:35 UTC
Would find this useful for libraries with a wireless scanner.  Staff could scan all the items they find lying around from in-house use and shelve them rather than cart them back to a computer, check them in for in-house use, and then shlep them all back to the shelves.  They could just upload all the barcodes into a barcode text box and check them in at once.
Comment 6 Owen Leonard 2019-10-05 00:25:56 UTC
Bug 19406 would simplify this feature a lot.
Comment 7 Sebastian Hierl 2020-01-29 13:15:41 UTC
We would welcome this feature as well and would be able to contribute to a development.
Comment 8 Sebastian Hierl 2020-01-29 13:24:27 UTC
(In reply to Sebastian Hierl from comment #7)
> We would welcome this feature as well and would be able to contribute to a
> development.

Actually, would anyone be interested in co-sponsoring? It seems that this would be a fairly easy (and affordable) thing to implement. Perhaps just two or three libraries coming together could make it happen.
Comment 9 Katrin Fischer 2020-01-29 21:29:30 UTC
(In reply to Sebastian Hierl from comment #8)
> (In reply to Sebastian Hierl from comment #7)
> > We would welcome this feature as well and would be able to contribute to a
> > development.
> 
> Actually, would anyone be interested in co-sponsoring? It seems that this
> would be a fairly easy (and affordable) thing to implement. Perhaps just two
> or three libraries coming together could make it happen.

Hi Sebastian, I've set 'seeking cosponsors' in the Change sponsored? field.
Comment 10 Benjamin Daeuber 2020-02-20 15:58:42 UTC
I think we'd be willing to fund some of this, but I'm curious what libraries want it to look like. There are a lot of things that happen on check-in (holds, transfers, notification of statuses). Do we want a table to appear (similar to the batch item modification tool) or do we want all those items to be checked in without user interaction and the various messages can be dealt with in other ways? For example, holds would later show up in the holds queue.
Comment 11 Christopher Brannon 2020-02-20 16:25:58 UTC
(In reply to Benjamin Daeuber from comment #10)
> I think we'd be willing to fund some of this, but I'm curious what libraries
> want it to look like. There are a lot of things that happen on check-in
> (holds, transfers, notification of statuses). Do we want a table to appear
> (similar to the batch item modification tool) or do we want all those items
> to be checked in without user interaction and the various messages can be
> dealt with in other ways? For example, holds would later show up in the
> holds queue.

I think options like forgiving fines, check-in date, and trigger holds would all be good options.

It should present a table of results.  If there is a fine, it should show if it was forgiven.  If there is a hold, there should be a button to confirm, confirm and print, or cancel (maybe), and when clicked, it would do it, but the buttons would disappear, but the table results remain intact.  If nothing, it will just show it was checked in and the date it was checked in for.
Comment 12 Benjamin Daeuber 2020-02-20 16:40:13 UTC
(In reply to Christopher Brannon from comment #11)
>
> I think options like forgiving fines, check-in date, and trigger holds would
> all be good options.
> 
> It should present a table of results.  If there is a fine, it should show if
> it was forgiven.  If there is a hold, there should be a button to confirm,
> confirm and print, or cancel (maybe), and when clicked, it would do it, but
> the buttons would disappear, but the table results remain intact.  If
> nothing, it will just show it was checked in and the date it was checked in
> for.

I like these ideas too, especially making trigger holds optional so this can be applied in a variety of situations. Trigger transfers would also need to be considered if libraries printed transfer slips or simply wanted to handle transfers some other way. 

Another option I'd like to throw out is to integrate batch check-in with batch item modification. When we process new items or remove them from display it would be easier if they could be checked in all at once.
Comment 13 Daniel Gaghan 2020-08-25 16:32:06 UTC
(In reply to Benjamin Daeuber from comment #12)
> (In reply to Christopher Brannon from comment #11)
> >
> > I think options like forgiving fines, check-in date, and trigger holds would
> > all be good options.
> > 
> > It should present a table of results.  If there is a fine, it should show if
> > it was forgiven.  If there is a hold, there should be a button to confirm,
> > confirm and print, or cancel (maybe), and when clicked, it would do it, but
> > the buttons would disappear, but the table results remain intact.  If
> > nothing, it will just show it was checked in and the date it was checked in
> > for.
> 
> I like these ideas too, especially making trigger holds optional so this can
> be applied in a variety of situations. Trigger transfers would also need to
> be considered if libraries printed transfer slips or simply wanted to handle
> transfers some other way. 
> 
> Another option I'd like to throw out is to integrate batch check-in with
> batch item modification. When we process new items or remove them from
> display it would be easier if they could be checked in all at once.

I agree with Benjamin Daeuber, item modification would be a great place to put the bulk check-in feature. Covid-19 closures has also made this feature even more useful.
Comment 14 Martha Fuerst 2020-08-25 17:34:59 UTC
Agreed that batch item modification seems like a great place to put this.

As for triggering transfers specifically, it would be useful if the results page included a message listing the titles/barcodes of items that were not "at home" after the check-in.

I'm not so worried about holds, since they'd show up as holds to pull.
Comment 15 Rebecca Coert 2020-08-28 19:59:32 UTC
I'd love to see Batch Check In made available with yes/no options on charging/forgiving fines, triggering holds, and setting the check-in date to something other than today.  I'd like to see a system setting similar to Batch Checkout where you can dis/allow the function AND limit it to certain patron categories.  

The criteria(s) to select yes/no needs to be provided at the time of the batch process (e.g.: similar to Batch Patron Deletion) to allow multiple users the ability to customize the process to their needs.  Someone using a barcode scanner in a large library may not want to activate holds because they're not near the items (letting the Holds Queue catch them).  Checking in items from COVID Storage may want to trap holds but not charge fines.  I think that the having more customization available, makes it more usable.
Comment 16 Rhiana 2020-08-31 15:10:44 UTC
Adding my vote for batch check-in - would find this functionality incredibly useful in numerous scenarios
Comment 17 Björn Nylén 2020-10-15 18:28:49 UTC
I was envisioning a checkin process that would support a batch of book placed on an rfid pad. The checkins would be processed asynchonously via ajax calls. That way you could process books without waiting for pageloads etc. We're handling quite a lot of stack requests that need a checkin before being svailable for patrons. Being able to process them by just passing them over the rfid pad without more interaction would be a time saver.
Comment 18 Michal Denar 2020-10-15 19:37:34 UTC
Hi,
if we process batch of documents we still need to process holds, items marked as lost, tranfers etc.  Let's talk how solve these situations in UI.
Comment 19 Christopher Brannon 2020-10-15 22:15:31 UTC
Perhaps the batch check-in process keeps track of items that have pending holds, transfers, alerts, etc.  At the end of the process, you are given a button to review this list.  Next to each in the list is a button to trigger the transfer or hold, or if there was an alert, it would show the message.

I think if this is done right, this could easily be a function that could be incorporated into the check-in functionality on the patron account.  When you check in all or selected items, if there are pending actions or alerts, you could review them.

In either place, if there are pending actions or alerts, if you try to navigate away from the screen, it would warn you.  Much like if you are editing a form and try to navigate away without saving.
Comment 20 Barbara Johnson 2020-10-16 13:51:53 UTC
We would love to have a batch checkin feature and I agree with all of Christopher's comments on how this might work.
Comment 21 Benjamin Daeuber 2020-10-21 19:56:15 UTC
I wonder if this isn't best broken off into multiple tickets? There are three places, all with different considerations:

1. standard check-in module

2. check-in on patron account

3. batch item modification

I don't know how much of this functionality would overlap in Koha's innards, but they all strike me as different workflows.
Comment 22 Christopher Brannon 2020-10-21 21:57:17 UTC
(In reply to Benjamin Daeuber from comment #21)
> I wonder if this isn't best broken off into multiple tickets? There are
> three places, all with different considerations:
> 
> 1. standard check-in module
> 
> 2. check-in on patron account
> 
> 3. batch item modification
> 
> I don't know how much of this functionality would overlap in Koha's innards,
> but they all strike me as different workflows.

I think the primary focus of this bug is the batch item modification.  If we can incorporate this feature in other areas down the road, then most of the work will primarily be done.  But I think the initial thought on this bug was for the batch tools.
Comment 23 Anna 2021-09-23 07:50:16 UTC
(In reply to Björn Nylén from comment #17)
> I was envisioning a checkin process that would support a batch of book
> placed on an rfid pad. The checkins would be processed asynchonously via
> ajax calls. That way you could process books without waiting for pageloads
> etc. We're handling quite a lot of stack requests that need a checkin before
> being svailable for patrons. Being able to process them by just passing them
> over the rfid pad without more interaction would be a time saver.

I agree on this one. Batch check-in of books on RFID pad would save time.
Comment 24 Nathan Walker 2022-02-11 20:56:31 UTC
Have there been any updates on this? Our team was discussing workflows for our department and a batch check-in feature for the batch-item modification would be greatly beneficial to us as well.
Comment 25 Rhiana 2022-03-23 15:43:53 UTC
YES! This would be an excellent addition to streamline various workflows - inventory, in house use, etc...
Comment 26 Noémie Labine 2022-04-11 20:09:40 UTC
+1 !
Comment 27 Mubassir Ahsan 2023-04-12 04:53:13 UTC
Hi,
We are looking for this for localuse records. Everyday users left used books on the table, we like to add them to localuse check in. We are using blutooth handheld scanner to capture barcodes. but it is difficult to put all the barcode one by one. So batch check in is very much needed. 

Thanks.
Comment 28 carthur@slolibrary.org 2023-04-28 22:15:03 UTC
Hi,

This sounds like a great, this would help a lot with our workflow! I would like to ask that it be more like batch item modification so I can use the scanner or copy/paste barcodes to check in!

Thank you,
Charlie
Comment 29 Madge Boldt 2023-09-22 12:59:46 UTC
I used the Inventory module to handle batch check ins for items that were still checked out and due prior to 2022. We wanted to remove these items, and batch delete did not allow it since they were still checked out. It's a decent workaround. Just be sure to only check in your own items, and create a report for collection development prior to removal from Koha.
Comment 30 Marcel de Rooy 2023-11-23 12:04:02 UTC
We're about six years further and many people would like the feature (we too) but nothing happened?
Comment 31 Thibault Keromnès 2024-01-29 16:43:36 UTC
Is it a duplicate of BZ 32019 ?
Comment 32 Marcel de Rooy 2024-01-30 12:14:00 UTC
(In reply to Thibault Keromnès from comment #31)
> Is it a duplicate of BZ 32019 ?

No, but they are definitely related.
Comment 33 Madge Boldt 2024-04-03 19:58:32 UTC
The ability to do a batch check in was resolved in Koha 23.05. There is a new Check In option at the bottom of Batch Item Modifications.
Bywater highlights the change in their Monday Morning Minute. https://bywatersolutions.com/education/monday-minutes-batch-item-improvement
Comment 34 Catrina Berka 2024-04-16 20:56:25 UTC
(In reply to Madge Boldt from comment #33)
> The ability to do a batch check in was resolved in Koha 23.05. There is a
> new Check In option at the bottom of Batch Item Modifications.
> Bywater highlights the change in their Monday Morning Minute.
> https://bywatersolutions.com/education/monday-minutes-batch-item-improvement

That feature is pretty great, but it doesn't address the need for this functionality for libraries using RFID pads.
Comment 35 Marcel de Rooy 2024-04-17 13:49:20 UTC
(In reply to Catrina Berka from comment #34)
> (In reply to Madge Boldt from comment #33)
> > The ability to do a batch check in was resolved in Koha 23.05. There is a
> > new Check In option at the bottom of Batch Item Modifications.
> > Bywater highlights the change in their Monday Morning Minute.
> > https://bywatersolutions.com/education/monday-minutes-batch-item-improvement
> 
> That feature is pretty great, but it doesn't address the need for this
> functionality for libraries using RFID pads.

Yeah. Going via batch item mod sounds like a workaround only.