Summary: | Wording of Fine Returned is confusing | ||
---|---|---|---|
Product: | Koha | Reporter: | Kelly McElligott <kelly> |
Component: | Fines and fees | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | amanda.jones, andreas.hedstrom.mace, caroline.cyr-la-rose, karen.fellows, martin.renvoize |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23091 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 14825 |
Description
Kelly McElligott
2020-01-08 16:14:51 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. When changing please keep capitalization rules in mind. 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. (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? 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. 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? Maybe "Fixed fine"? I would go with the simplest solution: "Fine" and "Fine Accruing". 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). 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. |