Reporting: LDP-based Reports (UXPROD-1319)

[UXPROD-2825] RA-Fine/fee Summary Cluster Created: 19/Nov/20  Updated: 07/Dec/21

Status: In Progress
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Reporting: LDP-based Reports

Type: New Feature Priority: TBD
Reporter: Angela Zoss Assignee: Angela Zoss
Resolution: Unresolved Votes: 0
Labels: po-mvp, report-cluster, reporting, team-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to REP-171 Fines/fees Open
relates to REP-88 Lost Item Paid for via Bursar Closed
Epic Link: Reporting: LDP-based Reports
Back End Estimate: XXL < 30 days
Development Team: Reporting
Report Functional Area(s):
Resource Access
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R3
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R3
Rank: GBV (MVP Sum 2020): R4
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Similar to UXPROD-2023 In Progress , but this is an aggregate instead of line items.

For every owning library, patron type, and fine type, calculate: total $ assessed, total $ paid, total $ forgiven, remaining balance. Filter by date range, include date range as column in table.

What is the correct date to use for the filter? The date the fee account was created? The date of last activity on this account? Maybe use date_created from feesfines_account by default.

How to calculate remaining balance? One option is "remaining" from accounts, but is that really the latest balance or just the result of one transaction? Is it overwritten each time (correctly)? Another option is to tally up payments and waives (and refunds??) and use that to calculate remaining?



 Comments   
Comment by Angela Zoss [ 20/Nov/20 ]

Some notes based on playing with the system a bit:

The feesfines_feefineactions table tracks a few different actions. In "type_action," you might see:

  • The same word that you see in the "fee_fine_type" column in feesfines_accounts; this is the action that occurs when a fine is created. the amount_action column and balance column should be the same for this action type.
  • "Paid partially"; payment where balance is not yet 0
  • "Paid fully"; balance should be 0
  • "Waived partially"; part of fine waived, some balance remaining
  • "Waived fully"; remaining balance waived
  • "Refunded fully": if patron has made a payment, it can be refunded (partially or fully)
  • "Credited fully": this is an interesting one; I think if you refund a payment when the balance is already 0, the system auto-creates a credit (basically, a payment of a negative amount) so the balance stays at zero and the patron doesn't go back to having a fine. I couldn't get the system to let me overpay, which would be another reason to issue a refund, so I'm not sure how all of that would show up.

Takeaways for this report: waiving/refunding should decrease the balance appropriately in the actions table, but might have to keep track of refunds and credits to make sure everything correctly totals up to the full original balance. Also, need to use "type_action" column to determine whether the amount in "amount_action" was added to or subtracted from the account balance. Looks like everything subtracts except for refund and the initial action taken to open an account.

Comment by David Bottorff [ 03/Feb/21 ]

Not sure how date range is applied in this report? Is it all actions within the date range? Or all fees incurred in that date range? For example, if an overdue fine was incurred three months ago, and I run a report for yesterday, will I see that something incurred three months ago was paid yesterday? But I wouldn't see when it was incurred? Some more detail would be helpful in ranking this.

Comment by Angela Zoss [ 03/Feb/21 ]

Good questions!

We proposed this report as an extension of https://folio-org.atlassian.net/browse/UXPROD-2023 (which is based on https://folio-org.atlassian.net/browse/REP-201 and https://folio-org.atlassian.net/browse/REP-254). I think we we're expecting this to be run as some kind of annual report, rather than something that produces a list of open fines/fees, but I think your question may still apply. I know from personal experience that some fines are incurred many years before they are paid...

Do you have a suggestion for how a date range filter might work best for this kind of report? Or in a report like this that you would find useful? If there might be different date filtering needs, we could also provide several date range options.

One thought, though, is that even if the filter is set for actions in a particular range, we could still include the information about the date the fee was incurred, regardless of when it occurred.

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