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
Seconding the usefulness of such a feature. -Marti
Hi I think this would be an excellent fuction and an obvious one for workflows.
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.
We'd find this useful too
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.
Bug 19406 would simplify this feature a lot.
We would welcome this feature as well and would be able to contribute to a development.
(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.
(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.
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.
(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.
(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.
(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.
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.
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.
Adding my vote for batch check-in - would find this functionality incredibly useful in numerous scenarios
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.
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.
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.
We would love to have a batch checkin feature and I agree with all of Christopher's comments on how this might work.
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.
(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.
(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.
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.
YES! This would be an excellent addition to streamline various workflows - inventory, in house use, etc...
+1 !
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.
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
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.
We're about six years further and many people would like the feature (we too) but nothing happened?
Is it a duplicate of BZ 32019 ?
(In reply to Thibault Keromnès from comment #31) > Is it a duplicate of BZ 32019 ? No, but they are definitely related.
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
(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.
(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.
Batch checkin would very very nice indeed. Fingers crossed it becomes a reality. Thank you.
Hi I think this would be an excellent fuction to add to Koha. Thanks.
I'm fiftheenthing this (or whatever number we're at). While we have RFID pads that can handle multiple items at a time (and we can checkout multiple at our self-checks), being able to scan a stack of items together (either check-in or check-out) would be a timesaver and would allow us to use the equipment to its fullest.
I agree, this would be a great fix for RFID libraries.
Batch check in would be a great time-saver.
Batch check-in would be a great function!
Created attachment 186374 [details] [review] Bug 19814: Add batch return functionality for RFID workflows This proof-of-concept adds batch return capability to the circulation returns page, designed primarily for RFID pad workflows while maintaining backward compatibility for single scan returns. Key Features: - Automatic RFID batch detection and processing with debouncing - Manual batch mode toggle in checkin settings - Single textarea element that adapts from single-line to multi-line - Batch results display with per-item status and messages Technical Implementation: - Backend auto-detects batch mode via newline presence in barcode input - Debouncing (500ms) prevents premature form submission during scanning for multi-line input - Textarea styling dynamically switches between single-line and multi-line modes - Batch processing reuses existing AddReturn() logic for consistency - All existing circulation rules, messages, and workflows preserved RFID Workflow: 1. RFID pad scans multiple items → deposits newline-delimited barcodes 2. Interface auto-expands to show all scanned items 3. Automatic submission after 0.5s delay 4. Batch results display with status for each item Manual Workflow: 1. Enable "batch mode" in circulation settings 2. Input field expands to textarea for multiple barcodes 3. Submit to see comprehensive batch results This is a proof-of-concept seeking user feedback before full development and refinement.
Created attachment 186375 [details] Testing guidance
# Batch Returns Feature - Test Plan for Librarians ## Overview This proof-of-concept adds batch return functionality to Koha's circulation returns page, specifically designed for RFID workflows while maintaining full backward compatibility with manual barcode entry. ## New Features 1. **Automatic RFID Batch Processing**: Scan multiple items with RFID pad - system automatically detects and processes all returns 2. **Manual Batch Mode**: Toggle in settings to enable textarea for typing/pasting multiple barcodes 3. **Comprehensive Results Display**: View status, messages, and details for each returned item 4. **Seamless Integration**: No changes to existing single-item workflow ## Test Scenarios ### Test 1: Traditional Single Item Returns (Should work exactly as before) **Purpose**: Verify existing workflow is unchanged **Steps**: 1. Go to Circulation → Check in 2. Enter a single barcode in the input field 3. Press Enter or click "Check in" 4. Verify item processes normally with all existing messages/alerts **Expected Result**: ✅ Identical behavior to current system --- ### Test 2: Manual Batch Returns **Purpose**: Test manual multi-barcode entry **Steps**: 1. Go to Circulation → Check in 2. Click the settings icon (⚙️) next to input field 3. Check "Enable batch mode for multiple returns" 4. Notice input field expands to textarea 5. Enter multiple barcodes, one per line: ``` 39999000001310 39999000001328 39999000001336 ``` 6. Click "Check in" **Expected Result**: - ✅ Batch results table appears showing each barcode - ✅ Success/failure status for each item - ✅ Individual messages (holds, transfers, etc.) per item - ✅ Regular checked-in items list also populated --- ### Test 3: RFID Batch Scanning (Key Feature) **Purpose**: Test automatic RFID workflow **Prerequisites**: RFID pad configured to output newline-delimited barcodes **Steps**: 1. Go to Circulation → Check in 2. Leave input field in default single-line mode 3. Place multiple items on RFID pad and scan 4. Observe interface automatically expands and shows all scanned barcodes 5. Wait approximately 0.5 seconds after scanning completes 6. System should automatically submit and process all items **Expected Result**: - ✅ Interface automatically switches to batch mode when RFID data arrives - ✅ All scanned barcodes visible in expanded textarea - ✅ Automatic submission after brief delay - ✅ Batch results showing all processed items --- ### Test 4: Mixed Success/Failure Results **Purpose**: Verify error handling in batch mode **Steps**: 1. Enable batch mode (manually or via RFID) 2. Enter mix of valid and invalid barcodes: ``` ValidBarcode123 InvalidBarcode999 AnotherValidOne456 ``` 3. Submit batch **Expected Result**: - ✅ Valid items show "Returned" status with green indicators - ✅ Invalid barcodes show "Invalid barcode" with red indicators - ✅ Appropriate error messages for each failed item - ✅ Successful returns still process normally --- ### Test 5: Special Circulation Scenarios **Purpose**: Test batch handling of holds, transfers, recalls **Steps**: 1. Return items that have various conditions: - Item with hold for pickup at current location - Item needing transfer to another branch - Overdue item - Item with recall 2. Use batch mode to return multiple items with different statuses **Expected Result**: - ✅ Hold notifications appear in batch results - ✅ Transfer messages displayed appropriately - ✅ All circulation messages preserved per item - ✅ Same behavior as single-item returns --- ### Test 6: Settings Integration **Purpose**: Verify batch mode integrates with existing return settings **Steps**: 1. Enable various return settings (Book drop mode, Forgive fines, etc.) 2. Test both single and batch returns with these settings active 3. Toggle batch mode on/off while other settings enabled **Expected Result**: - ✅ All existing return settings work with batch mode - ✅ Settings apply consistently to batch-processed items - ✅ No conflicts between batch mode and other options --- ## User Experience Questions for Feedback ### RFID Workflow 1. Does the automatic detection and expansion feel natural during RFID scanning? 2. Is the 0.5-second delay appropriate, or would you prefer longer/shorter? 3. Are all scanned barcodes clearly visible before automatic submission? ### Manual Batch Mode 1. Is the settings location for "Enable batch mode" intuitive? 2. Does the textarea expansion/collapse work smoothly? 3. Is the batch results table clear and informative? ### Results Display 1. Are success/failure indicators clear enough? 2. Do you get sufficient detail about each returned item? 3. Are error messages helpful for problem resolution? ### Overall Workflow 1. Does this enhance or complicate your returns process? 2. Would you use RFID batch returns in daily operations? 3. Any missing information or functionality? ## Known Limitations (Proof of Concept) - Bundle items and multi-part confirmations not yet tested in batch mode - Performance with very large batches (50+ items) not yet optimized - Some complex circulation scenarios may need additional testing ## Feedback Needed Please test these scenarios and provide feedback on: - Usability and workflow integration - RFID compatibility with your hardware - Performance with typical batch sizes - Any bugs or unexpected behavior - Suggestions for improvements --- _This is a proof-of-concept implementation seeking librarian feedback before full development._
OK.. this has been a lunch time project and I'd love a bit of feedback but I can't promise to get back to it especially soon.. hopeing it will inspire some others to have a play