| Summary: | Overriding fine on renewal will cause duplicate fines | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Barton Chittenden <barton> |
| Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
| Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | gmcharlt, kyle.m.hall |
| Version: | 3.18 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
Hm, I thimk the problem is not that there are 2 entries in accountlines - that seems correct to me, but both should be set to the same type on return? (In reply to Katrin Fischer from comment #1) > Hm, I thimk the problem is not that there are 2 entries in accountlines - > that seems correct to me, but both should be set to the same type on return? I feel that there should be no more than one entry in accountlines for a given row in the issues table... but the underlying problem is that using description as a lookup in the accountlines table is fundamentally broken. Bug 13790 adds a unique id to issues/old_issues -- adding a corresponding foreign key to accountlines table would fix the bug going forward. I think I disagree about the 'one line'. Once you renew the overdue process restarts and is not in any way related to the first one, I'd avoid mixing the data. It would make it really hard to see why the amount is as high as it is. With the 2 different due dates you get a clear clue. I see a renewal more like a new checkout - only that Koha doesn't treat a renewal as a new checkout as some other systems do (which is fine!). But I totally agree about the description being misused. I think we need to think about this a bit more and should note it as a use case/test case we need to test and make sure works properly. (In reply to Katrin Fischer from comment #3) > I think I disagree about the 'one line'. Once you renew the overdue process > restarts and is not in any way related to the first one, I'd avoid mixing > the data. It would make it really hard to see why the amount is as high as > it is. With the 2 different due dates you get a clear clue. > > I see a renewal more like a new checkout - only that Koha doesn't treat a > renewal as a new checkout as some other systems do (which is fine!). > > But I totally agree about the description being misused. > > I think we need to think about this a bit more and should note it as a use > case/test case we need to test and make sure works properly. Katrin, After discussion with Kyle Hall, I agree with you assessment: Closing the first fine and creating a new fine on renewal is standard behavior for Koha. This still leaves the issue of the second Fine not being closed. I'm going to mark the ticket as "RESOLVED/INVALID", and open a new ticket which specifically addresses the un-closed fine. I'll carry your comments regarding a test case forward to the new ticket. |
Overriding fine on renewal will cause duplicate fines. Because we use the due date in accountlines.description, and fines.pl uses accountlines.description to uniquely identify fines on update, changing date_due will create duplicate entries in accountlines. select date, amount, description, accounttype, amountoutstanding, lastincrement, timestamp from accountlines where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date: 2015-05-05 amount: 0.500000 description: O'Connor's annotated criminal codes plus. 05/04/2015 11:59 PM accounttype: F amountoutstanding: 0.500000 lastincrement: 0.500000 timestamp: 2015-06-08 12:42:27 *************************** 2. row *************************** date: 2015-06-08 amount: 4.500000 description: O'Connor's annotated criminal codes plus. 05/26/2015 11:59 PM accounttype: FU amountoutstanding: 4.500000 lastincrement: 0.500000 timestamp: 2015-06-08 02:02:40 2 rows in set (0.00 sec) Looking in old_issues, you can see that the item was renewed, and that date_due does match the second description... only the first accountlines entry is marked woth accounttype 'F' on return, however. select date_due, returndate, lastreneweddate, renewals, timestamp, issuedate from old_issues where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date_due: 2015-05-26 23:59:00 returndate: 2015-06-08 12:42:27 lastreneweddate: 2015-05-05 00:00:00 renewals: 1 timestamp: 2015-06-08 12:42:27 issuedate: 2015-04-13 09:23:20 To replicate: 1) check out an item 2) let the item go overdue and start accruing fines 3) renew the item 4) let the item go overdue again. Note that a second accountlines entry has been added 5) return the item. Note that only one accountlines entry is marked with accounttype 'F'.