Bug 19814 - Batch Check-in function
Summary: Batch Check-in function
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P1 - high new feature
Assignee: Martin Renvoize (ashimema)
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-14 15:50 UTC by Michal
Modified: 2025-09-11 13:41 UTC (History)
43 users (show)

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


Attachments
Bug 19814: Add batch return functionality for RFID workflows (16.35 KB, patch)
2025-09-11 13:35 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Testing guidance (5.48 KB, text/markdown)
2025-09-11 13:39 UTC, Martin Renvoize (ashimema)
Details

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.
Comment 36 Matthew Ciuccio 2024-06-10 19:59:04 UTC
Batch checkin would very very nice indeed. Fingers crossed it becomes a reality. Thank you.
Comment 37 Koha collecto 2024-11-11 20:24:26 UTC
Hi

I think this would be an excellent fuction to add to Koha. 

Thanks.
Comment 38 Avery Campbell (Butte County Library (CA)) 2025-03-05 20:11:54 UTC
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.
Comment 39 Lillian 2025-03-19 21:28:40 UTC
I agree, this would be a great fix for RFID libraries.
Comment 40 Tom Rice 2025-05-14 20:37:32 UTC
Batch check in would be a great time-saver.
Comment 41 ayoung 2025-07-22 20:57:27 UTC
Batch check-in would be a great function!
Comment 42 Martin Renvoize (ashimema) 2025-09-11 13:35:20 UTC
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.
Comment 43 Martin Renvoize (ashimema) 2025-09-11 13:39:04 UTC
Created attachment 186375 [details]
Testing guidance
Comment 44 Martin Renvoize (ashimema) 2025-09-11 13:39:37 UTC
# 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._
Comment 45 Martin Renvoize (ashimema) 2025-09-11 13:41:17 UTC
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