Bug 35440 - Partial refund triggers a 500 error
Summary: Partial refund triggers a 500 error
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 23.05
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-29 19:10 UTC by Esther Melander
Modified: 2023-12-01 14:50 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:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Esther Melander 2023-11-29 19:10:44 UTC
To recreate
1. Create a charge on a patron account of $150.00
2. Pay the charge as cash
3. Issue a refund, but only refund $5.00 as cash
4. See that it causes a 500 error

I should be able to issue a partial refund and have it show correctly in the transaction table.

Error statement:

Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to payout (5.00) is higher than amountoutstanding (0)'

May be connected to bug 30027 and previously fixed bug 8770.
Comment 1 Kyle M Hall (khall) 2023-11-29 19:16:58 UTC
If a Transaction type is chosen, the error does not occur.
Comment 2 Esther Melander 2023-11-29 19:25:06 UTC
Partial refund appears to fail depending on Transaction type.

For example, received a 500 error when selecting Cash or Check. But refund succeeded with Account Credit.
Comment 3 Esther Melander 2023-11-29 20:27:35 UTC
Some additional insight on why this is happening. The library had a circulation rule to refund lost item charge (only if unpaid).

To recreate
1. Set default refund policy to Refund lost item charge (only if unpaid)
2. Create a charge on a patron account of $150.00
3. Pay the charge as cash
4. Issue a refund, but only refund $5.00 as cash
5. See that it causes a 500 error

In this case Koha is trying to refund something that has already been paid, which can't happen based on the circulation rule. Instead of a 500 error, there should be "can't refund" warning.

As an extension of this bug, I can do a full refund, which also should not happen based on the circulation rule.
Comment 4 Kyle M Hall (khall) 2023-11-30 11:59:19 UTC
Esther, I cannot recreate the error on master or 22.11 using your test plan and the default data in Koha Testing Docker.

I was able to recreate by doing something a bit weirder through.


1. Create a charge on a patron account of $150.00
2. Pay the charge as cash
3. Issue a refund, but only refund $5.00 as cash
4. Void that refund
5. Issue refund on the "Credit has been voided" line

Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (5 + -5) is higher than original amount (5)'
 at /usr/share/perl5/Exception/Class/Base.pm line 88

https://monosnap.com/file/HSdtsLVcOinrV54hX5GLr98K2akXdz
Comment 5 Katrin Fischer 2023-12-01 14:40:44 UTC
We also see this in 22.11.10

There were no partial refunds, but full refunds using the button in the transactions table:

Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (2 + -2) is higher than original amount (2)'
Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (3 + -3) is higher than original amount (3)'
Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (3.00 + -3) is higher than original amount (3)'

Which makes no mathematical sense to me actually?
Comment 6 Kyle M Hall (khall) 2023-12-01 14:50:45 UTC
(In reply to Katrin Fischer from comment #5)
> We also see this in 22.11.10
> 
> There were no partial refunds, but full refunds using the button in the
> transactions table:
> 
> Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (2
> + -2) is higher than original amount (2)'
> Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction (3
> + -3) is higher than original amount (3)'
> Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Combined reduction
> (3.00 + -3) is higher than original amount (3)'
> 
> Which makes no mathematical sense to me actually?

The code uses absolute values which I think may be part of the issue.