Bug 8016 - Items are not tie to the transaction using "global" action.
Summary: Items are not tie to the transaction using "global" action.
Status: RESOLVED DUPLICATE of bug 2696
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P4 normal (vote)
Assignee: Kyle M Hall
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-27 15:55 UTC by Anthony Laquerre
Modified: 2019-05-06 12:40 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Payments Selection (10.27 KB, image/png)
2012-04-27 15:55 UTC, Anthony Laquerre
Details
Payments (16.67 KB, image/png)
2012-04-27 15:56 UTC, Anthony Laquerre
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Laquerre 2012-04-27 15:55:44 UTC
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
Comment 1 Anthony Laquerre 2012-04-27 15:56:10 UTC
Created attachment 9316 [details]
Payments
Comment 2 Chris Slone 2017-06-02 13:59:36 UTC
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.
Comment 3 Kyle M Hall 2017-07-05 11:12:28 UTC
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.
Comment 4 Chris Slone 2017-07-05 15:04:45 UTC
New bug submitted and linked to this one.
Comment 5 Katrin Fischer 2019-02-04 23:22:09 UTC
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 ***
Comment 6 Katrin Fischer 2019-02-04 23:22:23 UTC
Sorry, 18.05 :)
Comment 7 Marjorie Barry-Vila 2019-02-06 14:26:57 UTC
(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
Comment 8 Katrin Fischer 2019-02-06 14:39:55 UTC
Hi Marjorie, there is already one - let me find it!
Comment 9 Katrin Fischer 2019-02-06 14:41:45 UTC
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?
Comment 10 Marjorie Barry-Vila 2019-02-06 14:48:29 UTC
(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
Comment 11 Marjorie Barry-Vila 2019-05-06 12:38:40 UTC
(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
Comment 12 Katrin Fischer 2019-05-06 12:40:46 UTC
(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!