Refund not working as expected

Bug #1810429 reported by Dawn Dale on 2019-01-03
36
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

Bug Description

Refunds are not working as expecte on 3.2.2 Chrome and Firefox.
- When trying to issue a refund the “Refund” action does not do anything. When it is clicked the screen never changes.
- When trying to issue a refund putting an amount in the “Amount Received” will allow the payment to be processed and the total amount of the refund will be issued. The amount received is not relevant there just needs to be an amount in the box.
o If bills are due that the refund would cover they are deducted as expected.

I expect to be able to check the refund items and have the refund amount processed when "Apply Payment" is selected. It would be nice if the refund amount showed up in the "Amount Received" box when the billing lines are checked for refund.

I would expect the "Refund" action to behave the same way as processing the payment would work.

Chris Sharp (chrissharp123) wrote :

Confirming this and marking High importance since it affects direct service to the public.

Changed in evergreen:
importance: Undecided → High
status: New → Confirmed
tags: added: billing webstaffclient
James Fournie (jfournie) wrote :

I have determined this is a regression introduced by 4efaa63 (see LP 1749994)

Because of commit 4efaa63 the "Apply Payment" button will be disabled if the payment amount is 0. The refund functionality relies on clicking the "Apply Payment" button when the amount is zero, so it's impossible to issue a refund.

Reverting commit 4efaa63 resolves this issue but obviously doesn't solve both bugs.

James Fournie (jfournie) wrote :

Just spitballing a thought I had, but I wonder if the "Apply Payment" button should say "Issue Refund" or something when issuing a refund, or there should be a separate button that is greyed unless a refund is happening?

Kyle Huckins (khuckins) on 2019-05-23
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Kyle Huckins (khuckins) wrote :

I've pushed a branch here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1810429-refund-not-working-as-expected

Now, when a negative bill is selected, the disabled "Apply Payment" button will swap out with an "Issue Refund" button that properly handles the refund.

tags: added: pullrequest
Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
Bill Erickson (berick) on 2019-06-18
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

I like the Issue Refund button. An additional check is needed, though, to prevent users from seeing/clicking the 'Issue Refund' button when a mix of refundable and non-refundable transactions are selected. As it stands, when clicking the button with that scenario, the user gets an error alert for REFUND_EXCEEDS_BALANCE on the positive-balance transaction.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: added: needsrepatch
removed: pullrequest
Kyle Huckins (khuckins) wrote :

After some further discussion, I think this needs some discussion from the wider community - the refunds UI is overall fairly confusing. The Refund action itself doesn't do anything unless a negative bill is selected(possibly greying out this action when a positive bill or no bill is selected would be a good course of action?), and even then is only effectively a placebo(it brings up a modal saying what it's doing, but that's already done when you select a negative balance). It seems to me that the refund button might at this point be worth removing entirely.

The buttons I introduced might be confusing, as well. On the surface, it seems sensible, but issues arise with that mix of refundable and non-refundable transactions. A third button, "Refund & Apply Payment" might help with this, only displaying when a mix of refundable and non-refundable transactions are selected. It should also be noted though, that these buttons are functionally identical, so it's more a wording-change than anything.

tags: added: needsdiscussion
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers