Bug 5015 - fines not calculating properly
Summary: fines not calculating properly
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low critical (vote)
Assignee: Kyle M Hall
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-15 20:18 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
4 users (show)

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


Attachments
should be $0 due (39.40 KB, image/png)
2010-07-15 20:18 UTC, Nicole C. Engard
Details
should be $293 (66.96 KB, image/png)
2010-07-15 20:18 UTC, Nicole C. Engard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2010-07-15 20:18:08 UTC
Created attachment 2370 [details]
should be $0 due

I hope I'm wrong on this - but see the attached screenshots for 2 different patrons on HEAD.  Their fines are not adding up.
Comment 1 Nicole C. Engard 2010-07-15 20:18:29 UTC
Created attachment 2371 [details]
should be $293
Comment 2 Will Stokes 2010-07-30 05:22:22 UTC
Investigating this and it seems more of a problem with manual credits than a problem with the fines calculation.

The second example (balance 93) could well be correct.  Where the amount outstanding is 0.00 indicates that that fine has been paid in full.  The last 4 lines can be paired up so you have two invoice lines and two corresponding credit lines, each with amount outstanding now zero so the credit lines have been used to pay the invoice lines.

On an old but still recent version of koha when you enter a manual credit the outstanding column also displays the negative value and the total makes sense.  Testing on latest head though and it's easy to add a manual credit which gets entered as having no amount outstanding but without actually subtracting from any invoices with an amount outstanding.  This leads to discrepancy in the total and I think the first example illustrates that situation.

To my mind, when a manual credit is entered and it is to pay off outstanding invoices or part of, there should be a selection process to select which items are to be paid off and in which order.  The interface for this and use cases need to be thought through.  Potentially the old implementation for manual credits should be re-instated as current implementation appears buggy.

I will continue to investigate this issue and try and track down the exact cause.
Comment 3 Will Stokes 2010-08-15 21:34:46 UTC
I thought I had been able to reproduce this originally but don't seem to be able to now I'm looking at it again.  Can you note down the steps taken?

Note that the second attachment does look like it adds up correctly given writeoff and payment received lines but the first one definitely seems off.
Comment 4 Nicole C. Engard 2010-08-15 22:00:13 UTC
I'm closing this bug because I'm not sure now that it was a bug - it might have just been my math skills ;) If someone else can reproduce feel free to reopen.