Bug 3527 - writeoff doesn't handle locally-defined manual invoice types well
Summary: writeoff doesn't handle locally-defined manual invoice types well
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: D Ruth Holloway
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-12 03:13 UTC by D Ruth Holloway
Modified: 2012-10-25 23:03 UTC (History)
5 users (show)

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


Attachments

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


---- Reported by dbavousett@ptfs.com 2009-08-12 15:13:56 ----

In sub writeoff in members/pay.pl, there is a long WHERE clause looking for a long list of legacy accounttypes.  This prevents writeoff of any locally-defined ones.  Furthermore, this clause is un-needed, as the only calls to this subroutine will already be for positive-value amountoutstanding, since that's what pay.pl will be displaying to the user, and we already have the accountnum and borrowernum.

Patch will be on the way momentarily, but here is the diff:

diff --git a/members/pay.pl b/members/pay.pl
--- a/members/pay.pl
+++ b/members/pay.pl
@@ -199,7 +199,7 @@ sub writeoff {
     undef $itemnum unless $itemnum; # if no item is attached to fine, make sure to store it as a NULL
     my $sth =
       $dbh->prepare(
-"Update accountlines set amountoutstanding=0 where (accounttype='Res' OR accounttype='FU' OR accounttype ='IP' OR accounttype='CH' OR accounttype='N' OR accounttype='F
+"Update accountlines set amountoutstanding=0 where accountno=? and borrowernumber=?"
       );
     $sth->execute( $accountnum, $borrowernumber );
     $sth->finish;



---- Additional Comments From gmcharlt@gmail.com 2009-08-13 01:42:17 ----

Patch pushed to HEAD.

To speculate on the original motivation for permitting writeoffs only for specific account times, I would guess that it was a matter of policy.  I can see that a library might want to define certain types as ineligible for writeoffs, but that should be configurable, not hardcoded.

One exception might be if/when Koha supports true accrued overdue fines, in which case you might not want to permit writeoffs, at least not without deciding what happens to the item's status.



---- Additional Comments From nengard@gmail.com 2009-08-19 16:47:20 ----

Does this also fix this bug?  http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2632 



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

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

Unknown operating system Linux - Debian. Setting to default OS "All".
Actual time not defined. Setting to 0.0

Comment 1 Chris Cormack 2010-12-14 22:46:30 UTC
Is this fixed?