What are Batch Checkouts?
In Koha, there is a workflow that would allow libraries to batch checkout items.
To set this feature up, the system preference, BatchCheckouts, will need to be turned on. The other system preference, BatchCheckoutValidCategories, will also need to be filled out. This will indicate which patron category you would like to perform a batch check out. If there are more than one patron categories that you would like to include, use a pipe | to separate them. In this system preference, you will use the Patron Category Code that is set up in Admin, under Patron Categories.
This function will allow you to use an RFID pad that reads multiple barcodes or perform a batch check out for training internal use.
From the patron's account, there will be a new tab on the left-hand side called "Batch Checkout".
Clicking this option will allow the staff member to either add a file of barcodes or enter the barcodes into a text box for Koha to process.
If you have the SpecifyDueDate system preference enabled you will have the option to set a due date for the checkouts. Once you have added the barcodes of the items you are checking out, the screen will display:
Confirming the batch of checkouts, and these checkouts will also appear on the patron's checkout screen also.
How Do I End Checkouts to Clean Up Old Lost Items?
Often, libraries want a way to delete items that may still be checked out to patrons, but the items are years overdue and aren't likely to come back. The items cannot be deleted while they're still checked out, but returns might trigger refunds depending on circulation policies, or otherwise mark the item as found, so libraries need a way to be able to end the checkout without triggering a full return.
The
End Checkouts plugin provided this functionality prior to Koha 22.11, when the ability to end checkouts via batch item modification made it into Koha natively. The plugin will accept a list of barcodes and end the associated checkouts without triggering full return functionality, leaving any statuses and fees behind while still ending the checkout.
The change is also logged in the circulation log, clearly demonstrating that the checkout was ended via plugin.
This plugin was developed for libraries to fill a gap in default refund behaviors, the need for which has been somewhat mitigated with new 22.11 features, but this is still a valuable tool for libraries to have in their collection maintenance toolbox, empowering staff to clean up old checkouts from the staff client.
Check Previous Checkouts
There is a system preference that will check the patron’s circulation history to see if this item has been checked out in the past to this patron. In addition, libraries can set this option by patron category. Koha has given libraries a lot of flexibility with privacy and their patrons, this is a great example of how.
System Preferences
Let's first start with the system preferences, there are two:
CheckPrevCheckout - check borrower checkout history to see if the current item has been checked out before. Options a library can choose for this system preference:
- Do
- Don't
- Unless overridden by Patron Category Do
- Unless overridden by Patron Category Don't
When the value of this system preference is set to ‘do’, Koha will look at the patron’s circulation history to see if they have checked this item out before. An alert will show up on the screen indicating that the patron has indeed checked this item out. Staff will be prompted to allow the checkout to occur.
When the value is set to ‘Unless overridden by patron category, do’, this will check the patron’s circulation history unless the patron’s personal setting or the patron category setting specifically says not to.
When the value is set to ‘Unless overridden by patron category, do not, Koha will not check circulation history unless the patron’s personal setting or the patron category setting specifically says to check.
CheckPrevCheckoutDelay - Trigger a warning if the current item has been checked out no longer than X days ago. (Requires CheckPrevCheckout to be enabled. There is no time limit if 0 or empty).
Within the patron's account, there is an individual setting for checking previous checkouts, which overrides the setting of the patron category and of the CheckPrevCheckout system preference.
Patron Category Settings
Within each patron category, there is an option to set Check Previous Checkouts.
Choose whether patrons of this category by default are reminded if they try to borrow an item they borrowed before. The options are: inherit from system preference, no and try to override system preference, and yes and try to override system preference.
Because this option lives at the system level, the patron category level, and the patron level, there are several ways that this can be customized to work for your library.
The system preference CheckPrevCheckout will not work for patrons that have chosen to anonymize their reading history.
What does the system preference AllowcheckoutNotes do?
This system preference will allow patrons to add notes to an item they have currently checked out. This note will be sent to the Koha Staff Interface as well as emailed to the KohaAdminEmail address, the library's email address (set up in the system preference KohaAdminEmail or a branch email in the Libraries Module will receive an email. This email notice is called, CHECKOUT_NOTE. This by default will include the patron's name, the title of the book, and the note that was sent. This notice like all notices in Koha can be customized.
Steps
- Set the system preference allowcheckoutnotes to allow.
- When a patron is logged into their account in the OPAC there will be a new column visible to the patron on the items they have checked out.
Staff will see this note at the bottom of the staff interface.
How Can I End Checkouts without Triggering Return Options?
Prior to Koha version 23.05, libraries had limited options for ending old checkouts if they wanted to clean up long lost items from patron checkouts without also trigger return behavior. One interim solution was a plugin, the End Checkouts plugin, which bridged the gap between a recurring library partner need and the feature making it into Koha proper.
In case libraries missed the good news, though, this capability is in Koha now. When libraries submit a list of items for batch modification, the following option appears at the very bottom of the form:
As noted, a return this way will end the checkout without changing the lost status or affecting any fines incurred, and if a library is set up to deny return of withdrawn or damaged items, this will still end the checkout since it is not acting as a full return with all the normal things that would accompany return of a lost item.
Does Marking an Item Lost Automatically Block a Patron?
Whether a lost item automatically blocks a patron's account depends on several factors in a library's setup.
If a library is using overdue notice/status triggers and automatically marking long overdue items as lost via DefaultLongOverdueLostValue and DefaultLongOverdueDays settings, they may select the option to restrict the patron's account at some point in the overdue notification sequence (often, but not always, with the third billing notification).
Some libraries rely on the noissuescharge system preference to provide the restriction (as well as corresponding preferences NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees if they are using guarantee/guarantor patron relationships). If a library has the noissuescharge system preference set to block patrons from checking out items when their outstanding balance exceeds the threshold, marking an item lost manually might also be enough to immediately block the account.
However, it wholly depends on the value of the lost item and how high the fine threshold is for the library. For example, a library might block accounts owing more than $20.00; this means one overdue book costing $10.00 plus a $5.00 processing fee would not by itself block the account, but a second billed item or other outstanding fines might bring the account over the limit.
If a library always wants to block accounts at some point in their automated overdue timing, restricting via overdue notice/status triggers is the way to go, especially with the new option in the AutoRemoveOverduesRestrictions preference as of 23.11, which allows libraries to decide whether a restriction should be lifted when all late items are returned or when the item causing the debarment is returned. This means, however, that manually marking an item lost to bill the patron may not innately restrict the account if the amount is below the noissuescharge limit.
If a library's policies are to block accounts at certain dollar amounts, then they may not opt to block with overdue notices and instead rely on outstanding fees to kick in with noissuescharge. In this case, they do not have different blocking behaviors based on how the items were marked lost or overdue - manual or automatic, as soon as the bill is applied, the system preference will sort out whether they should be blocked.