Fees/Fines (UXPROD-792)

[UXPROD-499] Future Fees/Fines: Collections agency interactions: when patron still pays library Created: 11/Apr/18  Updated: 06/Dec/22

Status: Draft
Project: UX Product
Components: Fees/Fines
Affects versions: None
Fix versions: None
Parent: Fees/Fines

Type: New Feature Priority: TBD
Reporter: Holly Mistlebauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Unassigned-from-Holly, appreport, feesfines, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: JPEG File Collection Agencies.jpg    
Issue links:
Gantt End to Start
has to be done after FOLIO-1953 SPIKE: propose an approach for schedu... Closed
Relates
relates to UXPROD-1117 Manual transfer of fees/fines to burs... Closed
relates to UXPROD-105 Future Fees/Fines: Update current aut... Closed
relates to UXPROD-1858 Future Fees/Fines: Collections agency... Draft
Potential Workaround: Holly: I split UXPROD-499, Collections Agency Interactions into two features. UXPROD-499 now covers only those cases where the collection agency communicates with the patron, but the library still collects the money. New JIRA issue UXPROD-1858 covers cases where the collection agency collects the money and then passes it to the library. The workaround for this feature (UXPROD-499) is that the library would need to be able to run a query to identify the fees/fines to be sent to collections (based on their unique criteria) and to update the database with a new "staff only info" fee/fine action indicating the action taken with a date/time stamp. I'm not sure how easy that will be to do, so it may make more sense to do this in Q1 2020. This feature doesn't need the kind of testing others do--usually one person at the library does this--making this available at the last minute won't be such a big issue.
Epic Link: Fees/Fines
Front End Estimate: Medium < 5 days
Front End Estimator: Holly Mistlebauer
Front-End Confidence factor: Low
Back End Estimate: Medium < 5 days
Back End Estimator: Holly Mistlebauer
Estimation Notes and Assumptions: Hasn't been discussed at all yet.
Development Team: Vega
Report ID (pre-May 2019): ID441
Report Contact(s):
Joanne Leary
Report Functional Area(s):
Resource Access
PO Rank: 0
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R5
Rank: FLO (MVP Sum 2020): R5
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R5
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R5
Rank: TAMU (MVP Jan 2021): R5
Rank: U of AL (MVP Oct 2020): R5

 Description   

Institutions work with collections agencies in a variety of ways, so this feature has been split into three parts:
1. Some institutions "sell" the debt to the collection agency, which is like a transfer and will be handled by UXPROD-105 Closed
2. Some institutions "pay" the collection agency to collect the debt, but the patron still has to pay the library UXPROD-499 Draft (Chicago is an example)
3. Some institutions have the collections agency collect the debt, along with the agency fee, and then the debt payment is passed to the library from the collections agency UXPROD-1858 Draft (Cornell is an example)

Survey of institutions available at https://docs.google.com/spreadsheets/d/1tBzbWo3albd1133eue0xwe8x8D_Wa5uHuBhyHowLXoY/edit#gid=0

Attached image contain in-progress requirements for this feature.



 Comments   
Comment by Holly Mistlebauer [ 15/Aug/18 ]

From: David W. Bottorff <dbottorff@uchicago.edu>
Sent: Tuesday, July 17, 2018 1:49 PM
To: Holly L. Mistlebauer <hlm7@cornell.edu>
Subject: RE: Working with collections agency...

Hi Holly,

What we really need are two reports and an ability to flag user records:

A report we can customize to export a list of patrons and the total amount owed based on the following criteria:
a. Patron expiration date
b. Fee type
c. Billing date

We use this report to identify patrons who have expired within the last year with lost item fees only (we don’t care about fines), and whose lost items were billed at least 3 weeks prior to the report being run. We pull other information from the user record, such as mailing address, email address, phone number, patron group, etc.

We then need a field that we can use to flag the patron as being turned over to collections. We have both a yes/no field that only a few staff can change, as well as a pop-up text note that all staff can see. This lets us identify those patrons whom we’ve paid to turn over to collections.

We also run a report nightly on those who have been turned over to collections to see if their balance has changed in any way. This report, and the other report are exported and turned over to the collections agency to update their records.

Currently, this is a relatively manual process, and one we’re still working out the kinks of. However, the company, Unique Collections, has done a lot of work with other major ILS vendors such as Aleph and I believe voyager and alma, to more fully automate the process. That would be great in the long term but isn’t needed at launch.

So we don’t need any changes made to the bills themselves at all. Although having an “action” on the bills wouldn’t be a bad thing, it’s more important for us to have this at the patron level. We need some basic reporting features (possibly this could be done via the data warehouse, but I don’t know for sure, especially as we need the payment info to be very much up-to-date, not stale). We also need a means of flagging/identifying patrons as being within the collections process.

Separately, we have a way of flagging users as deceased, so we can exclude them from the collections process in advance, as well as so we can flag them if the collections agency informs us they are deceased, as this ends their process.

I’m happy to discuss this at greater length. I believe our needs are significantly more modest than what others who do actual transfers, will need.

Best,
David

Generated at Fri Feb 09 00:08:25 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.