Bug 24376 - Wording of Fine Returned is confusing
Summary: Wording of Fine Returned is confusing
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 14825
  Show dependency treegraph
 
Reported: 2020-01-08 16:14 UTC by Kelly McElligott
Modified: 2020-02-11 12:46 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kelly McElligott 2020-01-08 16:14:51 UTC
With 19.05 Koha Fines were given new descriptions.  We moved away from F and FU fines to Fines Accruing and Fine Returned. However, libraries find that the Fine Returned confusing when the item has been renewed and / or lost. 

Example:
If an item has been lost, the fine will stop accruing and therefore get the description of Fine Returned. However the item is not returned but the fine has, in essence, stop accruing.  

Or if an item has been overdue, then renewed.  The first fine will have stopped accruing and be given a Fine Returned when really the item has been renewed and could potentially get more fines.

Recommendations of the wording could be "Fine Final" instead of "Fine Returned"
Comment 1 Karen Fellows 2020-01-08 16:33:23 UTC
This is confusing for our library staff since we are a library that doesn't charge fines.  We only bill when an item is lost or damaged.  When we migrated to Koha, our old bills were brought over as migrated fines from our previous system and they now have an account type of Fine (Returned) however the items were not returned--they are all long lost.  We would like the wording changed as Kelly described.
Comment 2 Katrin Fischer 2020-01-08 19:44:10 UTC
When changing please keep capitalization rules in mind.
Comment 3 Amanda Jones 2020-01-29 16:44:10 UTC
We also take issue with the wording (Returned). We prefer the to replace it with (Outstanding) as Final may not be the case if that item is renewed and then becomes late again.
Comment 4 Katrin Fischer 2020-01-29 21:17:46 UTC
(In reply to amanda.jones from comment #3)
> We also take issue with the wording (Returned). We prefer the to replace it
> with (Outstanding) as Final may not be the case if that item is renewed and
> then becomes late again.

Hi Amanda, if the item is renewed and becomes overdue again, this will create a new line in the accounting table (fine accrueing). But I think that's another reason why returned might not be a good pick here - if it's also used for renewals?
Comment 5 Amanda Jones 2020-01-29 22:22:41 UTC
Patrons can also see this wording on the OPAC. They might be thrown off by one fine stating FINAL then seeing that fine begin to accrue again.
Comment 6 Katrin Fischer 2020-01-29 22:28:54 UTC
I agree about final not being ideal. Not being a native speaker probably doesn't help much here... but is the opposite of an accrueing fine?

Static? 
Frozen?
just: Fine 
Unpaid?
Comment 7 Caroline Cyr La Rose 2020-02-05 17:13:59 UTC
Maybe "Fixed fine"?
Comment 8 Andreas Hedström Mace 2020-02-05 21:24:29 UTC
I would go with the simplest solution: "Fine" and "Fine Accruing".
Comment 9 Martin Renvoize 2020-02-11 11:13:37 UTC
I took a look at the code here and found that the renewal case at least 'should' use 'RENEWED' as it's status.. but it appears that AddRenewal is seldom called for renewals, instead, AddIssue is called again and we end up with the 'RETURNED' status.

I'm not sure what the worth of having such detailed status's for OVERDUE fines is if I'm honest at this point.. We should be focusing on the state of the fine more than the state of the circulation in these fields and so I would propose 'ACRUING' and 'FIXED' as the status's for OVERDUE's.. (along with 'FORGIVEN' and 'VOID' which are further account states via the staff client actions).
Comment 10 Martin Renvoize 2020-02-11 11:31:34 UTC
To clarify that a little..

Existing states:

[%- CASE 'UNRETURNED' -%]<span> (Accruing)</span> # Set when fine is first created and still accruing
[%- CASE 'RETURNED'   -%]<span> (Returned)</span>     # Set in C4::Circulation::AddReturn (can be called via AddIssue)
[%- CASE 'RENEWED'    -%]<span> (Renewed)</span>     # Set in C4::Circulation::AddRenewal (can be called via AddIssue, but seldom is)
[%- CASE 'REPLACED'   -%]<span> (Replaced)</span>      # 
[%- CASE 'REFUNDED'   -%]<span> (Refunded)</span>    #
[%- CASE 'FORGIVEN'   -%]<span> (Forgiven)</span>       # Inside _FixOverduesOnReturn, if 'exemptfine' is true
[%- CASE 'VOID'       -%]<span> (Voided)</span>                  #
[%- CASE 'LOST'       -%]<span> (Lost)</span>                       # Set in C4::Circulation::LostItem (if WhenLostForgiveFine is disabled)

I think it would make sense to reduce that list to `ACCRUING` and `FIXED` for overdues that are unpaid.. and then allow for 'FORGIVEN', 'VOID', and 'PAID' to signify 'payment' actions on the lines.

This may have a knock on effect with our WhenLostForgiveFine handling if the item is subsequently found and returned.. I believe there's another bug already discussing that case however.