Sahra: Transit slips/notes on account for patrons who have fines or fees. haven’t talked about what we should do? could we have a conversation about what the best practices are? We’ll get a paging slip for a patron that owes money, so they likely won’t be able to loan it. At the same time we don’t want to not send the item because they might clear their account up. What’s the best route?
Notes
UCSD: pull item out of stream, billing dept notifies patron about the fine. 7 days to clear, otherwise we send it back.
→ You could create a new cancelation reason to notify the patron. If your reason is clear (we can’t lend due to fines owed) that might be “good enough”? Having consistent language systemwide for canceling would be good.
Want to catch this at the point of paging, not at the circulation desk. This is the direction we’ll go until the blocks are in place.
Sahra: I found this page on modifying and/or adding new request cancellation reasons in Alma. I propose we add a new reason referencing fines/fees on the user's account and use the Cancellation Note open text field when cancelling the request to include more details, such as what the user needs to do (i.e. clear the fine and re-request). I'm totally open to the Cancellation Reason Code. Maybe something like "Blocked Due To Fines/Fees" or "Patron Owes Fines/Fees"?? Can we discuss at an upcoming meeting?
Ingred: Question about cancelling requests due to fines: If UCSD cancels a request because the user owes us $100, would that request then move to the next UC with an available copy, or will it be cancelled entirely? Does either outcome figure into what information we might want to include in the request cancellation note?
Actions
Draft language for cancellation reason to notify the patron?
”Can’t lend due to fines owed…”
Should be able to differentiate text because of the cancellation reason.
Develop in tandem with Disco OST?
Request can be canceled from the patron’s home institution and it will stop all forward movement.
→ Sahra will add a new cancelation reason on her end and do some testing with Ross.
10/9
Sahra added cancelation reason on UCR sandbox and we tested for requests placed by me which were canceled on her end. Because no emails are send within the sandbox we don’t know if I would have been notified -OR- if the request was pushed to the next campus in line.
next steps: add another member (Ingred) and continue to test, but this time in the live environment. We’ll be able to test emails that are (or aren’t sent) and test if canceling the request pushes it to another campus.
Depending on those results, we’ll have to make a determination on if there’s a better process for cancelling a request so it wouldn’t be pushed to another campus (e.g. contacting patron’s home institution and asking for it to be cancelled at the source).