[Koha-bugs] [Bug 3230] Automatic Credit when Lost item is returned

[bugzilla-daemon at liblime.com]

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3230


Joe Atzberger <joe.atzberger at liblime.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joe.atzberger at liblime.com




--- Comment #1 from Joe Atzberger <joe.atzberger at liblime.com>  2009-05-18 19:46:41 ---
This would have to be optional, since upon charging replacement cost for a LOST
item, many libraries will have already ordered the replacement and spent the
money, regardless of whether the original eventually is returned or not.  

Also, a longoverdue LOST item for which a fine is charged is OFF the patron's
record.  It is no longer checked out.  We can identify that the item was lost
by items.itemlost.  But there is a data failure when you ask "who lost it?",
i.e. "who gets the refund?".  

You might assume it was the most recent row in issues or old_issues, but that
would be wrong if the item was just marked lost by staff, or by the inventory
process.  It might be good to implement a items.lastissuedto field referencing
borrowernumber.  

The fine in this scenario is already paid, too, and potentially moved off to a
proposed old_accountlines table.  This proposed feature could only operate to
the extent that (old_) accountlines has not been purged.  

There is a definite problem with accountlines table as is.  Consider that we
have no no way to identify a Lost Item fine that has been refunded.  Therefore
if an item was lost, paid for and returned multiple times, there is no way to
know which of the several "losers" is owed a refund, if any.  

The next consideration is performance.  This is happening at the most
speed-dependent operation: checkin.  Doing a brute force LIKE search on
descriptions (an ugly hack previously implemented for fines) is unacceptable
for, say, 5 years of accountlines.  Something like lastissuedto is the only fix
for that, since then we can at least rely on the accountlines.borrowernumber
index.

So it would require:
 ~ syspref
 ~ accommodation by fines overhaul
 ~ items.lastissuedto

Note that no system will accommodate the scenario where the barcode has been
reassigned, the item deleted, or the patron deleted.  


-- 
Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.