Bug 21884 - Writeoff "amount" changed from positive values to negative values.
Summary: Writeoff "amount" changed from positive values to negative values.
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 18100
Blocks:
  Show dependency treegraph
 
Reported: 2018-11-26 18:23 UTC by Alex C
Modified: 2024-07-04 20:37 UTC (History)
1 user (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
Example of pos/neg writeoff values. (118.57 KB, image/png)
2018-11-26 18:23 UTC, Alex C
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex C 2018-11-26 18:23:16 UTC
Created attachment 82653 [details]
Example of pos/neg writeoff values.

Hi,

This is not a recent issue, I discovered it either after 17.05 or 17.11 update.
Before the update, writeoff amounts were displayed in "red positive numbers", but after the update, writeoff amounts became "green negative numbers" just like payments.

This is not an issue if it's just humans reading it, but it becomes an issue when doing accounting and stats, when I was totaling fines during a certain time range, positive/negative values cancel each other and provide inaccurate total fine amounts. I used ABS() as a workaround, but I hope it can be fixed globally to keep it uniform.

Please see attached pics.
Also ticket "#49563: Difference in positive and negative values in writeoff charges" has some discussion as well. I also spoke to Kyle regarding this issue at KohaCon18.

Thanks.
Alex C
Comment 1 Tomás Cohen Arazi (tcohen) 2018-11-27 12:37:38 UTC
Alex, could you please give us some steps to reproduce the issue? Or is it related to old vs. new data on your db? (generated by the change obviously)
Comment 2 Alex C 2018-11-27 17:26:03 UTC
Hi Tomas,

I think it's old vs new data prior/after an update, you can take a look at this patron's account: 20165100573549, if you filter only "writeoff" numbers, you can see that writeoff balances prior to 2017 were all positive values shown in red (like fines), but after 2017 they were all negative values shown in green like payments.

I believe if you pull a SQL report to show writeoff balances from any db it might show the same thing, I don't think it's specifically our DB. I think you can use the timestamps when 17.05 or 17.11 updates were done to see if the values started to look differently prior/after the updates.

Hope my explanation made sense ... sorry I can't find the SQLs I wrote back then when I first discovered this, we were doing library system-wide stats on fines and accounts sent to collection, that's how I found some fines were canceling each other out because of the pos/neg values.

Thanks.
Alex.
Comment 3 Katrin Fischer 2020-04-13 21:43:11 UTC
I believe this was due to bug 18100, fixed by bug 15894  We also spotted this and removed some of the payment options from the GUI back then to avoid the issue in the db. 

As this hasn't been revisited or got more comments since end of 2018, I am hopeful that bug 15894 fixed it for good. Please reopen if there is still an issue after updating to a recent version.
Comment 4 Alex C 2020-08-20 20:57:15 UTC
Hi Katrin,

Yes I haven't updated this bug because there wasn't an actual fix so far to uniform the positive write-off values and negative write-off values. Is there a way or patch to batch modify all the previous (red) positive write-off amounts into (green) negative amounts?

Thanks.
Alex.
Comment 5 Katrin Fischer 2020-10-18 16:39:01 UTC
I believe if the database updates haven't taken care of it, there is no official fix and this might need some work locally :(
Comment 6 Katrin Fischer 2023-10-07 23:49:40 UTC
(In reply to Katrin Fischer from comment #5)
> I believe if the database updates haven't taken care of it, there is no
> official fix and this might need some work locally :(

This turned out to be true. See bug 29559 for some help with the clean-up if you want to do it.