Bug 4438 - incorrect "Budget total exceeds period allocation" error when editing fund
Summary: incorrect "Budget total exceeds period allocation" error when editing fund
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) major (vote)
Assignee: dev_patches
QA Contact: Bugs List
URL: admin/check_parent_total.pl
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-03 04:20 UTC by Galen Charlton
Modified: 2013-12-05 20:04 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
fix the ajax calculation (1.47 KB, patch)
2011-01-13 10:58 UTC, dev_patches
Details | Diff | Splinter Review
patch proposed should work for 3.2. (1.60 KB, patch)
2011-01-13 11:49 UTC, dev_patches
Details | Diff | Splinter Review
patch appliable for master (1.28 KB, patch)
2011-01-13 12:12 UTC, dev_patches
Details | Diff | Splinter Review
followup proposed (2.14 KB, patch)
2011-02-18 22:43 UTC, dev_patches
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:27:11 UTC


---- Reported by gmcharlt@gmail.com 2010-05-03 16:20:40 ----

Editing a fund, then trying to save it, can result in a 'Budget total exceeds period allocation' blocking the save even when there are funds available.

To reproduce:

[1] Create a budget with $1000 allocated
[2] Create a child fund with $900 allocated
[3] Edit that same fund, say to change the name.

Result:

You are prevented from saving the fund.

Expected result:

You should be able to save the fund.

Analysis:

The web service admin/check_parent_total.pl is not taking into account the possibility that you are editing an existing fund and subtracting that fund's current allocation before seeing if the new allocation will not go over the limit set by the parent budget.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:27 UTC  ---

This bug was previously known as _bug_ 4438 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4438

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Katrin Fischer 2010-07-12 13:29:46 UTC
You are still prevented from editing funds in Koha version 3.01.00.142.

I think this is a big problem, as libraries will want to change amounts, expenditure, encumbrance, etc.

After you start ordering you can't just delete your fund structure and start over to make such a correction.
Comment 2 dev_patches 2011-01-13 10:58:30 UTC Comment hidden (obsolete)
Comment 3 dev_patches 2011-01-13 11:49:01 UTC Comment hidden (obsolete)
Comment 4 dev_patches 2011-01-13 12:12:45 UTC
Created attachment 2983 [details] [review]
patch appliable for master
Comment 5 Chris Cormack 2011-01-13 21:34:20 UTC
Pushed, please test
Comment 6 MJ Ray (software.coop) 2011-02-04 09:13:53 UTC
This bug is mentioned in:
Bug 4438: incorrect "Budget total exceeds	period allocation" error when editing fund http://lists.koha-community.org/pipermail/koha-patches/2011-January/013592.html
Bug 4438: incorrect "Budget total	exceeds period allocation" error when editing fund http://lists.koha-community.org/pipermail/koha-patches/2011-January/013593.html
Bug 4438: incorrect	"Budget total exceeds period allocation" error when editing fund http://lists.koha-community.org/pipermail/koha-patches/2011-January/013594.html
Bug 4438: incorrect "Budget	total exceeds period allocation" error when editing fund http://lists.koha-community.org/pipermail/koha-patches/2011-January/013595.html
Comment 7 dev_patches 2011-02-18 22:43:12 UTC
Created attachment 3184 [details] [review]
followup proposed
Comment 8 Chris Cormack 2011-02-21 19:18:44 UTC
Follow up patch needs signoff
Comment 9 Chris Cormack 2011-03-14 07:54:06 UTC
Follow up patch pushed, please test and mark resolved
Comment 10 Fred P 2012-01-12 21:35:10 UTC
This bug remained unresolved for us, and we traced the problem to an error in the floating point calculation. We are using Koha 3.5. The process is the same as that described in the initial filing:

We edit a fund, in our case, changing the fund name. Even though we did not change the fund total, we get a "budget total exceeds period allocation" error. 

aqbudgets.pl pulls totals from the acq.js script, that in turn calls on the check_parent_total.pl script. 

check_parent_total.pl runs a comparison between the fund total that is submitted in the aqbudgets.pl edit screen, and the unallocated amount left from the budget_period_total. They will usually be equivalent.

However somewhere in the process a floating point error is being generated, making the total a tiny bit greater than the unallocated amount, locking the budget fund for editing by generating the error (returncode=2), as listed above.

A simple solution is to multiply the values on both sides of the comparison by 100, and truncate the decimal places. Here is our suggested solution that solves the problem:

File: check_parent_total.pl
Line around 103

if ( $parent_id) {
   if ( ($total > $sub_unalloc ) && $sub_unalloc )  {
       $returncode = 1;
   }
} elsif ( ( floor($total*100) > floor($budget_period_unalloc*100)) && $budget_period_unalloc ) {
   $returncode = 2;

} else {
   $returncode = 0;
}
Comment 11 Katrin Fischer 2012-01-15 19:02:46 UTC
Hi Fred,
can you give me a test plan to reproduce the problem?
I checked the lines you mention on current master and they seem unchanged. But I am not sure the problem is still there. 

  99 if ( $parent_id) {
 100     if ( ($total > $sub_unalloc ) && $sub_unalloc )  {
 101         $returncode = 1;
 102     }
 103 } elsif ( ( $total > $budget_period_unalloc ) && $budget_period_unalloc ) {
 104     $returncode = 2;
 105 
 106 } else {
 107     $returncode = 0;
 108 }
Comment 12 Jared Camins-Esakov 2012-12-31 00:31:06 UTC
There have been no further reports of problems so I am marking this bug resolved.