Bug 19876 - Koha::Account->pay() does not exit specific fine loop when balance is used up
Summary: Koha::Account->pay() does not exit specific fine loop when balance is used up
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 14825
  Show dependency treegraph
 
Reported: 2017-12-22 15:10 UTC by Nick Clemens
Modified: 2020-02-06 09:13 UTC (History)
3 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 Nick Clemens 2017-12-22 15:10:41 UTC
If a patron selects specific fines to pay and enters an amount less than all of those fines the loop will continue through all fines. This can be problematic for lost fines which are not paid or not paid fully as they will be marked 'Paid for...' and returned
Comment 1 Nick Clemens 2019-01-08 16:49:32 UTC
To recreate:
1 - Create a manual fine for a patron (or find one with fines)
2 - Check out an item to this patron
3 - Ensure the item has a lost charge
4 - Mark the item lost via a method that will not check it in (MarkLostItemsAsReturned syspref) 
5 - Note the item is checked out to patron and they are charged
6 - From patron go to Accounting->Make a payment, select all, 'Pay selected'
7 - Enter an amount less than the value of the first fine and pay
8 - Payments are calculated correctly, however, the item is now checked in
9 - View the item on the 'items' tab of the biblio
10 - The 'Paid for?' section notes the item has been paid for
11 - Pay a partial amount again
12 - Paid for now has doubled info
Comment 2 Tomás Cohen Arazi 2019-01-08 18:20:07 UTC
This could be solved by replacing ->pay for ->add_credit + ->apply (they were designed for that). I'll take a look!
Comment 3 Jonathan Druart 2019-12-12 09:58:03 UTC
Hi Tomas, do you plan to work on this one?
Comment 4 Tomás Cohen Arazi 2019-12-12 10:54:15 UTC
(In reply to Jonathan Druart from comment #3)
> Hi Tomas, do you plan to work on this one?

Not in a short term. Ask Martin, as he was working on replacement methods.
Comment 5 Tomás Cohen Arazi 2019-12-12 10:56:00 UTC
In the described case, the API for adding credits against a list of debit lines could be used, and it wouldn't suffer from this.
Comment 6 Martin Renvoize 2020-01-10 17:00:36 UTC
UX question.. currently, we just work through the selected items in the order they're sent to the routine I believe.. should there be a precedence for what types of charges are paid off first?
Comment 7 Martin Renvoize 2020-02-06 09:13:12 UTC
The bug here was inadvertently fixed by bug 22982 in which a check on amountoutstanding was introduced.

We should still short-circuit the loop at some point to prevent needless processing, but at this point that change is now an architectural enhancement rather a major bug.