There has been some discussion about the usability of the change calcualation feature from bug 11373. Adding a bug to collect comments and suggestions in a central spot in hope that we will be able to improve things prior to the 19.05 release :)
I'll start: 1) I am not a fan of the extra step the modal adds: - you click 'confirm' - modal appears to 'confirm' There is a lot of text on the modal which I think makes it hard to 'parse' quickly. It also feels a bit 'extra' as the change was already shown before I clicked 'confirm'. - Could we improve/simplify the text? - Could we add keyboard shortcuts to yes/no like in other spots? - could we make the amount stand out more visually as this is the most important information? 2) For me it's not clear what goes into which input field and I think it might get worse with translation. We got: Amount paid : (additonal space should be removed) Collect from patron: It's not clear to me what does input fields each are meant for :( Should it be: Collect_ed_ from patron? - Could we improve the labels to be more clear? - Could it make sense to set the fields apart a bit visually as the change calculation is optional?
I totally agree here, I just haven't had a moment to comment before now.. I'd really like this functionality cleaned up.. I think I even put a mockup screenshot in the original bug if I remember correctly with how I perceived it looking.
Not sure how to get this moving, but I feel we should not release with the feature as is.
Created attachment 87591 [details] Screenshot showing partial payment There has been no reaction to this so far from the initial developers, I am updating it to a bug as I think we will get negative feedback on it as it stands now :( To show one of the issues I have added a screenshot.
To repeat steps from screenshot: - Have an account with multiple fines & charges - Click 'Pay amount' - Enter the Amount paid Suggestion: Leave amount collected empty and only calculate 'change to give' if it's entered. I'd also love some visual separation to make the Amount paid stand out more and show that the other 2 fields belong together. Also: Collect form patron > Collected from patron Amount paid : > Amount paid:
I fail to trigger the described modal from comment#2 right now. Wonder if we already changed something there?
Found the mmodal... it appears when you click confirm.
Talked to the chaps here (mostly techies who hang around libraries!) after seeing some discussion about this on IRC this morning and we couldn't see what the point of the "collected" option was? If you collect 20 currency units in order to pay 5 currency units off a 15 currency unit bill in order to leave 10 currency units due, does Koha really need to record the 20, rather than just the 5 unit payment? Surely the person in the library handling this would be able to do the 15 unit change themselves? Or are people somehow linking Koha payment records to EPOS transactions?
I think the idea was to help calculate, but the GUI right now seems confusing compared to the 'before' and would require extra input. Looking at the screenshot I think what I did 'wrong' was: I wanted to pay a partial amount of the amount outstanding. Use case: "But I only have 6.00 with me..." So I said: - Pay amount - Amount paid: 6.00 - I didn't change the other input fields - I shoudl have changed: Amount collect_ed_ to say 6.00 - Change would have been: 0.00 But having to enter 2 fields to have the display make sense seems not good to me.
Created attachment 95619 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden.
Created attachment 96394 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com>
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt
Created attachment 97229 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com>
That was a 'fun' rebase...
Giving this a bump for speedy QA and backport. We've got folks broadly confused about what "Amount paid" and "Collect from patron" mean. Will put in a new bug to consider alternate wording, but this patch would at least prevent them from accidentally paying more than intended.
(In reply to Andrew Fuerste-Henry from comment #15) > Giving this a bump for speedy QA and backport. We've got folks broadly > confused about what "Amount paid" and "Collect from patron" mean. Will put > in a new bug to consider alternate wording, but this patch would at least > prevent them from accidentally paying more than intended. Did you test the patch? Could you add your stamp on it?
Just tested, this did not work for me. What I did: - Create manual invoice for $100 - Click Pay on that specific fee - Leave amount paid at $100 - Set collect from patron to $50 - Submit payment - Koha marks the entire fine as paid off
Field "Collected from patron" is used for calculation how much change back to patron if pay more that "Amount being paid". This patch don't solve situation if librarian want to make partial write off (Collected from patron < Amount being paid). From my point of view patch works.
Created attachment 97840 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com>
(In reply to Michal Denar from comment #19) Michal, I'm having trouble reconciling what you say in comment #18 and what you say in comment #19. In #18 you say "This patch don't solve situation if librarian want to make partial write off (Collected from patron < Amount being paid)." I read that as you saying amount collected *should* be allowed to be less than amount being paid. In #19 you say "It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden." I read that as you saying amount collected *should not* be allowed to be less than amount being paid. So I'm not understanding something. Right now, with this patch applied I am still able to make a payment where amount being paid is $10 and amount collected is $5. Koha treats this as a payment of $10. It does not in any way indicate that I have taken actual payment for $5 and essentially forgiven the other $5. I think this makes for very misleading bookkeeping.
I'm investigating this at the moment as I'm also now seeing some very strange behaviour.. I think something may have gone awry in the rebase. The intention was indeed to prevent collection of less than payment prescribed. The validation routines seems to break on decimals is where I'm at currently..
I partically agree with Andrew that solution and texts are "inaccurate". But "Collected from patron" has field for calculation function. So if we talk about partially write off feature, we should use clear way that every librarian user understand from UI&texts. Maybe like https://prnt.sc/qs0raw
Created attachment 97873 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com>
Created attachment 97874 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side.
(In reply to Michal Denar from comment #22) > I partically agree with Andrew that solution and texts are "inaccurate". But > "Collected from patron" has field for calculation function. So if we talk > about partially write off feature, we should use clear way that every > librarian user understand from UI&texts. Maybe like https://prnt.sc/qs0raw I think that's a different enhancement and should be logged as it's own bug.. I'm really just trying to clarify the existing functionality as it stands... I've attached a followup that prevents undercollection at the server end and returns an error message. However, I'm still stuck on the clientside validation, it seems that our jquery validate library simply falls over at a value of 100 for 'minimum'.. I've reported a bug upstream and spend ages trying to debug it. Bug: https://github.com/jquery-validation/jquery-validation/issues/2311 Fiddle: https://jsfiddle.net/ashimema/1uxysdap/17/
See bug 24495 for changing the wording on this interface.
Created attachment 97877 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 97878 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
I'm signing this off, as it did block me from submitting a payment where collected < paid. But one non-blocking bit of weirdness -- it gives me different error messages depending on whether or not I'm paying off the whole fine. If amount being paid = total amount payable and amount collected < amount being paid, Koha lets me click confirm and then pops up a big yellow alert saying "You must collect a value greater than or equal to [amount being paid]". If amount being paid < total amount payable and amount collected < amount being paid, Koha immediately makes amount collected red and adds a little red message next to it reading "Please enter a value greater than or equal to [amount being paid]." So, it works, but the inconsistency is weird.
Created attachment 97885 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com>
Created attachment 97886 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side.
The issues should all be fixed now.
Created attachment 97888 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 97889 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
It works! Great!
(In reply to Andrew Fuerste-Henry from comment #29) > I'm signing this off, as it did block me from submitting a payment where > collected < paid. But one non-blocking bit of weirdness -- it gives me > different error messages depending on whether or not I'm paying off the > whole fine. > > If amount being paid = total amount payable and amount collected < amount > being paid, Koha lets me click confirm and then pops up a big yellow alert > saying "You must collect a value greater than or equal to [amount being > paid]". > > If amount being paid < total amount payable and amount collected < amount > being paid, Koha immediately makes amount collected red and adds a little > red message next to it reading "Please enter a value greater than or equal > to [amount being paid]." > > So, it works, but the inconsistency is weird. I somehow missed this comment.. did you mean the wording in the yellow alert box was inconsistent? I can happily fix that here as a followup.. just wanted to clarify what you meant.. That box should now only appear if you have javascript disabled, but it's nice to know we're catching things in that case too.
I meant it was inconsistent in that sometimes it gave that big yellow box and sometimes it just gave some red alert text within the payment form. I don't have strong feeling about this, but it would be a little cleaner if it always errored out in the same way. I've got no problem with pushing this as-is, maybe changing it in another bug.
Aha, I see.. so at this point if you have javascript enabled you should only ever see the client-side validation.. i.e. the red hints in the form itself. If you have javascript disabled you should only ever see the yellow alert box.. i.e. the serverside validation will be triggered. Hopefully, that makes sense
Note to self.. opening a bug to add the same logic to the point of sale page.
Created attachment 98833 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 98834 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Rebased... again
Template process failed: file error - parse error - /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt line 453: unexpected end of input at /kohadevbox/koha/C4/Templates.pm line 122 FAIL koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt OK filters OK forbidden patterns OK git manipulation OK js_in_body OK spelling OK tt_valid FAIL valid_template parse error - /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt line 453: unexpected end of input
Created attachment 99323 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 99324 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 99325 [details] [review] Bug 22359: (follow-up) Fix rebase error
Created attachment 99337 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 99389 [details] [review] Bug 22359: Improvements to payment collection inputs This patch attempts to clarify the uses of the various input fields on the paycollect screens. It does this by adding validation to the form such that entering a 'collected' value that is lower than the 'paid' value is now forbidden. Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 99390 [details] [review] Bug 22359: Prevent undercollection at the server This patch adds some additional handling to prevent undercollection of fees at the server side. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Nice work everyone! Pushed to master for 20.05
Pushed to 19.11.x for 19.11.04
this is missing a dependency for 19.05.x, no backport