http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3230 Joe Atzberger <joe.atzberger@liblime.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joe.atzberger@liblime.com --- Comment #1 from Joe Atzberger <joe.atzberger@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.