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 | ||
| Issue links: |
|
||||||||
| Potential Workaround: | Holly: The workaround would be for a library to run a query against the database (or data warehouse?) to see which items have been lost more than 6 months and cross reference the circulation data for the item to determine if the lost item is work replacing. | ||||||||
| Epic Link: | Fees/Fines | ||||||||
| Front End Estimate: | Medium < 5 days | ||||||||
| Front End Estimator: | Holly Mistlebauer | ||||||||
| Front-End Confidence factor: | Low | ||||||||
| Back End Estimator: | Holly Mistlebauer | ||||||||
| Development Team: | Vega | ||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 1 | ||||||||
| 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): | R4 | ||||||||
| Rank: 5Colleges (Full Jul 2021): | R3 | ||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||
| Rank: Grand Valley (Full Sum 2021): | R2 | ||||||||
| Rank: hbz (TBD): | R2 | ||||||||
| Rank: Hungary (MVP End 2020): | R2 | ||||||||
| Rank: Lehigh (MVP Summer 2020): | R5 | ||||||||
| Rank: Leipzig (ERM Aut 2019): | R5 | ||||||||
| Rank: MO State (MVP June 2020): | R4 | ||||||||
| Rank: TAMU (MVP Jan 2021): | R4 | ||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||
| Description |
|
Purpose: To supply the selectors with a list of items that have been lost and not replaced by patrons. Would be best to wait about 6 months before producing report, giving time for lost items to appear. Selector would want to see information about the item's usage--may decide to not replace item if not used much. |
| Comments |
| Comment by Holly Mistlebauer [ 15/Aug/18 ] |
|
EMAIL TRAIL OF CONVERSATION WITH CHICAGO ABOUT WHY THEY NEED THIS REPORT AT GO-LIVE: From: David W. Bottorff <dbottorff@uchicago.edu> Hi Holly, The report for lost items that patrons have paid for has the same purpose—to allow selectors to determine if the item should be replaced. The fact that an item has been paid for simply means that we don’t wait as long to bring this to the selector’s attention—if the patron has paid for the item, we assume it isn’t coming back. So it sounds as though the replacement consideration report would work for our purposes, especially if we could set our parameters to include paid for items more quickly than other items. In other words, show items that have been missing for X days/months but also should items that have been paid immediately or after Y days/months. That’s the reason we’d want this at go live, because we’d have items paid for more quickly than we’d otherwise run such a report. I’d also assume that the amount of time an institution wants to wait for missing items to show up would be configurable within the report, yes? Not everyone would want 6 months hard coded into the report, presumably. Does that make sense? Best,
From: Holly L. Mistlebauer hlm7@cornell.edu Hi David. Thanks for your responses… The Quick Paydown feature was identified by the RA SIG before the Fees/Fines Sub-Group was established. It’s strange because in my mind I can hear you talking about it. I will email the SIG to see who asked for it. The Lost items for replacement consideration report could show if the patron has paid for the replacement of the book, but that is not really its purpose. The purpose of this report is for the selectors to determine if an item should really be replaced regardless of whether a patron has paid for it or not. They will look at the stats we provide and then make a decision. We are waiting 6 months just to give the lost book a chance to show up. Please down grade this report from “go live” if you are o.k. with that. The report you are referring to does not yet exist because no one has asked for it. You are saying that you want a report that lists lost items that the patrons have paid for? What would this report be used for? What kind of data would you want to see? Thanks, From: David W. Bottorff <dbottorff@uchicago.edu> Holly, As far as paydown goes, lI’m not on the fee fines subgroup and have never felt strongly about the pay down option. I’m ambivalent about having it at all, frankly, as I see it as an opportunity for staff error. I think you’re mixing me up with someone else, maybe David Williams from tamu or Marc canney at Lehigh? As far as the in app report, I’ve been thinking of this as something we need for daily operations and hence as go live. You’re correct that we might be able to wait a quarter or so before running it for missing items, it I assume this report or a close variant would also include items paid for by patrons, which we’d want to run immediately. Is that understanding correct? David On Jun 21, 2018, at 12:50 PM, Holly L. Mistlebauer <hlm7@cornell.edu> wrote: I have two more fees/fines questions from the gap analysis. I have cc’d David because he asked for one of these features… UXPROD-104: Paydown outstanding fees/fines is listed as NOT NEEDED by Chicago. David is the champion of this feature and we wouldn’t even be doing this without his suggestion. Chicago may not need this at GO LIVE but I think David will want it at some point. UXPROD-842: Fees/Fines in-app report: Lost items for replacement consideration is listed as needed for GO LIVE by Chicago. We were thinking that this report would be used to notify selectors of lost items that they may want to replace—we would wait about 6 months to give lost items a chance to magically appear. If your plan is to use this to report items that were lost when you used OLE and you want to report them now, that’s fine. No one else needs this for GO LIVE so I just want to confirm that Chicago really does. It’s fine if you do. Thanks much, |
| Comment by Erin Nettifee [ 27/Mar/19 ] |
|
Duke would like this information to be available / reportable but does not see a need for it to be an in-app report. |
| Comment by Anya [ 29/Mar/19 ] |
|
Comment from the March meeting : the ability to pull a CSV or get to the data is a must . |