[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





--- Comment #4 from Joe Atzberger <joe.atzberger at liblime.com>  2009-05-18 22:37:34 ---
(In reply to comment #2)
> The only thing I have to add to this is adding a note someplace on the
> Patron's record. 

This is unrelated to David's proposed feature.

> Some Patrons, who will remain nameless, have been known to
> abuse the system often mysteriously returning lost materials to circumvent
> fines. 

Encouraging returns is part of the idea of charging overdue and replacement
fines.  That's not abuse, that *is* the system.  The proposal is not suggesting
that overdue fines be refunded on return, since that would be silly.

> If it happens once, it might be a Staff error. When it happens, oh ten
> or twelve times, one starts to suspect a Patron.

Suspect them... of returning books?

> Judging by the 27 votes over there I'd say the default option on
> install might want to be "on" not "off" for this enhancement. I think you can
> change out the "many" up there to "some" or perhaps "penny wise pound foolish".

Since one person can cast up to 200 "votes" on one ticket, 27 (or even the
current value of 62) is not necessarily indicative of widespread interest.

>> But there is a data failure when you ask "who lost it?",
>> i.e. "who gets the refund?".  
> 
> That's not an optimal data structure then.

For these purposes it is not just sub-optimal, but actually a point of failure.

>> 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 staff assigned lost ought probably be better than the
> automatically assumed lost date, just as you might want a different sort of
> lost for Patron reported losses. I think we had a missing, dusty (meaning not
> seen in X amount of time), and a Patron reported variety. The dusty list could
> be pulled as a report (obviously not relevant here, but neat in general for
> collection development purposes as those could be reconsidered.) 

We don't get to pick as developers.  Lost statuses are authorized values.  I'm
not sure what you mean when you say one status should be "better" than another. 

> Wasn't stated, might be known, but I would certainly hope that the
> borrowernumber reference would be an encrypted call for anonymity's sake.

The borrowernumber certainly would NOT be encrypted, nor would it be meaningful
to encrypt it.  That is just the key from the borrowers table, and it is used
almost everywhere in Koha.  It wouldn't be displayed or exported via OPAC.

>> 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.  
> 
> Or a given Librarian can flex their research muscle and go query
> Amazon or Alibris for a rough replacement value. Given that a Library doesn't
> charge more than face value, or face value plus a fee (or ideally market or
> maximum value) this would work.

You seem unfamiliar with the way this already works.  The feature proposed is
to handle refund of paid replacement-cost fines.  The acquisitions/cataloging
process currently handles the assignment of actual cost and replacement cost. 
Such values are assumed to have been populated, charged and paid before this
proposed feature becomes relevant.

>> 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.  
> 
> Maybe I'm not clear on this, but it seems like the relationship
> you perceive isn't the status a system ought have. If a book is not checked out
> everything is kosher. If it's missing but in the Library, it ought be on the
> shelves available to a circ clerk to recheck it in or perhaps out of the
> building but in the returns pile. If it is checked out and exceeds a given late
> period and is converted to a lost item, it ought to show on check in. Mostly
> these options are either in or out. I'm not sure how the situation you're
> describing would occur. Do you mean for an agency card or a family or parent
> child card?

The kind of card doesn't matter.  As I have ranted numerous times previously,
Koha fines are certainly not correctly designed for what we and reasonable
libraries want to do with them.  You correctly identify situations where the
proposed feature does not apply.

>> 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.
> 
> Again, not sure why last issued wouldn't be the logical first stop.

Because it doesn't yet exist as a field.


-- 
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.