Fees/Fines
(UXPROD-792)
|
|
| 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: |
|
||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||
| 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: 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> 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: 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, |