Created attachment 9315 [details] Payments Selection Hi, We have a problem with how the process of paying fine is currently done. Look at the 2 images. In the Pay fines page. There is currently a difference between buttons Group 1 : ("Pay" + "Writeoff") Group 2 : ("Pay amount","Write off all", "Pay selected") Group 1 is done on the specific item level. Group 2 is done globally using a logic to pay the oldest fine. ( That's my understanding ... :-)) If you look at image : Payments.png, you will see the difference. The payment for 10$ is done using "Pay selected". The payment for 5$ is done using "Pay". This scenario is valid for all buttons from group 1 and group 2. The problem is really the link to the item that is currently lost when using buttons from Group 2. Staff find it really hard to talk about their account because of that. It's impossible to know what the 10$ really apply to. This is a simple example, but sometime patron will return 5 books with 5$ fines for each. You will do "Pay Selected" (group 2) the 25$ will be applied but you will never be able to know what it was apply exactly. Is it possible to still link the item to the transaction using button from Group 2 ? Let me know if you need more infos. Thanks, Anthony
Created attachment 9316 [details] Payments
Hi, This is still an issue and is in need of fixing as it presents a potentially more severe problem when paying the replacement charge for an item if the item is still checked-out to the patron. So, for example, if your cronjob is set to mark an item lost and you charge patron's for lost items, using anything other than the 'pay' button will not remove the item from the patron's checkouts after the charge has been paid. To replicate: 1.) Set preference WhenLostChargeReplacementFee to 'Charge' 2.) Edit the record of a checked-out item to the lost status indicated by your DefaultLongOverdueChargeValue. Note: To keep the item checked-out, this must be done by opening and editing the item's record (not directly from the items tab of the bibliographic record). You can also use an item that your longoverdue cronjob marked. 3.) Confirm that the item is still checked-out to the patron and that the replacement fee was charged. 4.) Use pay selected, pay amount, write off, or write off all with the replacement charge and confirm the action as normal. 5.) The charge will be removed but the item will still be checked-out to the patron's record.
Chris, can you file a separate bug for your report? I sounds like a related but separate issue to me. As for the initial issue of not having the relationship between fees and payments stored, I do believe Bug 14826 will solve the underlying problem, and one it is pushed we can work on revealing this data in the interface. (In reply to Chris Slone from comment #2) > Hi, > > This is still an issue and is in need of fixing as it presents a potentially > more severe problem when paying the replacement charge for an item if the > item is still checked-out to the patron. So, for example, if your cronjob is > set to mark an item lost and you charge patron's for lost items, using > anything other than the 'pay' button will not remove the item from the > patron's checkouts after the charge has been paid. > > To replicate: > > 1.) Set preference WhenLostChargeReplacementFee to 'Charge' > 2.) Edit the record of a checked-out item to the lost status indicated by > your DefaultLongOverdueChargeValue. Note: To keep the item checked-out, this > must be done by opening and editing the item's record (not directly from the > items tab of the bibliographic record). You can also use an item that your > longoverdue cronjob marked. > 3.) Confirm that the item is still checked-out to the patron and that the > replacement fee was charged. > 4.) Use pay selected, pay amount, write off, or write off all with the > replacement charge and confirm the action as normal. > 5.) The charge will be removed but the item will still be checked-out to the > patron's record.
New bug submitted and linked to this one.
This has been fixed with Koha 18.11 - you can now accesss all information about which accountlines a payment paid and which payments went towards paying a fine. See: bug 2696 *** This bug has been marked as a duplicate of bug 2696 ***
Sorry, 18.05 :)
(In reply to Katrin Fischer from comment #6) > Sorry, 18.05 :) Hello Katrin, Indeed we can see the details of a global payment in the account of the user but in the cash report (reports/cash_register_stats.pl), only one line appears and not the details. I'm going to open a new bug for that. Thank you, Marjorie
Hi Marjorie, there is already one - let me find it!
No, you are right, there isn't. I was thinking of the slip printing for some reason. Improving the report would certainly be nice, it was added before account_offsets was reintroduced. A difficulty might be making it work for old and new data?
(In reply to Katrin Fischer from comment #9) > No, you are right, there isn't. I was thinking of the slip printing for some > reason. Improving the report would certainly be nice, it was added before > account_offsets was reintroduced. > > A difficulty might be making it work for old and new data? Thank you for your reply. I think if it worked for the new data, that would be enough. Thanks Marjorie
(In reply to Katrin Fischer from comment #9) > No, you are right, there isn't. I was thinking of the slip printing for some > reason. Improving the report would certainly be nice, it was added before > account_offsets was reintroduced. > > A difficulty might be making it work for old and new data? Hi Katrin, A new bug is open to have payment detail on cash register https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22845 Regards, Marjorie
(In reply to Marjorie Barry-Vila from comment #11) > (In reply to Katrin Fischer from comment #9) > > No, you are right, there isn't. I was thinking of the slip printing for some > > reason. Improving the report would certainly be nice, it was added before > > account_offsets was reintroduced. > > > > A difficulty might be making it work for old and new data? > > Hi Katrin, > A new bug is open to have payment detail on cash register > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22845 > > Regards, > Marjorie Thx Marjorie!