Fees/Fines (UXPROD-792)

[UXPROD-2245] Add option to get Actual Cost for lost item from order Created: 28/Jan/20  Updated: 21/Jun/23

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

Type: New Feature Priority: P2
Reporter: Holly Mistlebauer Assignee: Stephanie Buck
Resolution: Unresolved Votes: 0
Labels: Current-ff-work, feesfines, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: JPEG File Slack1.JPG     JPEG File Slack2.JPG     Microsoft PowerPoint UXPROD-2245 Flowchart.pptx     Microsoft PowerPoint UXPROD-2245 Flowchart_ORIGINAL.pptx    
Epic Link: Fees/Fines
Development Team: Vega
PO Rank: 0
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R4
Rank: hbz (TBD): R4
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R4
Rank: U of AL (MVP Oct 2020): R4

 Description   

As part of the MVP, the Lost Item Fee Policy has two options for charging a patron for a lost item. We can charge a set amount or actual amount. The actual amount is found manually. This could be a third option, where the actual amount comes from the order. Some may think this could replace the current manual actual cost option, but I can think of reasons why you wouldn't want to just automatically charge the patron the order price. Also, not every item in the library will have an order price. Some are too old. Also, some items may cost more or less to replace now. The RA SIG will need to discuss this thoroughly. We are busy with the MVP right now so I have added this as a placeholder for future discussion.

Update added on June 7, 2022

There are several ways this could be handled. Assumptions I have made:

  • All items (I am thinking of older items at this point) will not have the order price available in FOLIO.
  • Even for items that have the order price available, sites may not want to blindly charge the patron the original order price--replacing the item may cost more now, or less.

Given the assumptions above, we could do the following...

  1. Add a setting to the Lost Item Fee Policy when ACTUAL COST is selected to indicate "Automatically charge order price if available?" This will work for libraries that don't want to do any manual processing of the lost item. If a patron complains, they have the option of waiving part of the fee. Additional options...
    • Add setting that if order cost if over X, don't bill it automatically
    • Add if order cost is Y or less, automatically bill the default amount
    • Add if order cost is over Z, automatically bill Z
  2. For sites that use ACTUAL COST but don't want anything billed automatically (they want to review the bill first), the "Lost items requiring actual costs" processing page would populate the "Actual cost to patron" field with the order cost. The staff member would then either leave the cost as is, or raise/lower it as needed. Additional option...
    • Allow the library to set a default cost to be used and then it can be changed in the "Lost items requiring actual costs" processing page
  3. Regardless of the "Automatically charge order price if available?" setting, if the order price does not exist the site will need to process the lost item manually using the "Lost items requiring actual costs" processing page.

(Note: See the attached file UXPROD-2245 Draft Flowchart.pptx to see how this process would work.)



 Comments   
Comment by Holly Mistlebauer [ 28/Jan/20 ]

Slack message from Erin to Holly on January 23...

Comment by Holly Mistlebauer [ 28/Jan/20 ]

Slack messages from Holly to Erin on January 23 and 28...

Comment by Holly Mistlebauer [ 28/Jan/20 ]

Erin, I made you a "Watcher" for this new feature in UXPROD...

Comment by Thomas Trutt [ 02/Jun/22 ]

Depending on how this shapes up I will chat with CU about re-ranking higher.. I believe this would fall in line closer to what we would want for an 'actual cost' system. I'd like to see a fallback though similar to Voyager. If a replacement cost was set at the item level that was billed if no amount was set the default replacement cost was billed. 

Comment by Holly Mistlebauer [ 07/Jun/22 ]

Thomas Trutt: We will be discussing this feature at the June 9 RA SIG meeting.

Comment by Erin Nettifee [ 08/Jun/22 ]

I'm a bit "mentally" stuck on this in the sense that the price of the item when ordered often doesn't reflect the replacement cost of the item now - e.g., if I ordered a book ten years ago and now it's out of print, it might cost me significantly more to get the same item now, and I might want the "actual cost" to reflect that.

I still think the use case as outlined makes sense (bringing in the Order cost), but I don't want to lose sight of the fact that in many cases a library may still want to be able to change the fine amount being charged to the patron.

Comment by Holly Mistlebauer [ 09/Jun/22 ]

Erin Nettifee: I totally agree. That is why I have been hesitant about blindly billing the patron the order cost.

Comment by Olga Kalachinskaya [ 21/Jun/23 ]

Our library does prefer the automatic actual cost as we mostly use it as a deterrent for students at the end of the semester. When they see that they owe us money, they prefer to return the items. However the replacement cost has to be real, otherwise it would just make no sense and make people angry for no good reason. After we send the replacement bills, 95% of items come back. We wouldn't want to manually update all of them to just get them back.
We also prefer that the price would come from the item records. Our order records could include multiple items; sometimes there are no order records (for example for equipment as it's purchased differently from other types of materials); order records not always preserved forever.
We really need this functionality to be more automatic, so we don't have to do so much manual work.

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