Bug 3230 - Automatic Credit when Lost item is returned
Summary: Automatic Credit when Lost item is returned
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: PC All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-18 06:21 UTC by David Schuster
Modified: 2012-10-25 23:09 UTC (History)
4 users (show)

See Also:
Change sponsored?: Seeking cosponsors
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:08:04 UTC


---- Reported by dschust1@gmail.com 2009-05-18 18:21:53 ----

1 - When a lost item is found and returned the system doesn't alert the person checking in the item.

2 - nor does it provide a credit to the original person that has paid for the item.

Plano ISD would like to see this functionality added to Koha and is seeking co-sponsors or those that may already have this under development.



---- Additional Comments From 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.  



---- Additional Comments From abesottedphoenix@yahoo.com 2009-05-18 20:39:18 ----

         Make it so, Number 1! Good catch, David. Lost items can generate some heat for a Library, particularly when the people that return them are in high places. The only thing I have to add to this is adding a note someplace on the Patron's record. Some Patrons, who will remain nameless, have been known to abuse the system often mysteriously returning lost materials to circumvent fines. If it happens once, it might be a Staff error. When it happens, oh ten or twelve times, one starts to suspect a Patron.

(In reply to comment #1)
> 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.  
> 

         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".  I believe that old, ugly, DRA had this sort of feature with an audio clue. You'd probably know better than I what Horizon had.


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

          That's not an optimal data structure then.


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

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


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


> 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.  
> 
              
              Maybe not, but late books are fun to talk about. :D

http://www.washingtonpost.com/wp-dyn/content/article/2009/05/10/AR2009051002045.html

              Tsk, tsk, tsk, Bonnie Isman's dishonour in dodging my drinking duel is rubbing off on her Trustees...




---- Additional Comments From jransom@library.org.nz 2009-05-18 21:16:16 ----

We have this curretnly working very smoothly in 2.2.9. Since we are in the process of moving to 3.0 we do want this feature in the very near future. Will talk to Chris Cormack who is doing our work, happy to cosponsor.



---- Additional Comments From joe.atzberger@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.



---- Additional Comments From jransom@library.org.nz 2009-05-18 22:54:07 ----

How it currently works in Koha 2.2.9

A book is either marked lost by a staff member OR is marked lost by becoming long overdue.

Both instances generate an invoice for the replacement cost of the item in the Patron's account.

When the Patron pays that invoice several things happen:

1. The invoice is marked paid.
2. The item is returned off the borrowers card.
3. Its lost status remains in place.
4. A note is generated which says "Paid for by <patrons barcode number> and the date.

Then, later when the lost book is returned or found, as it comes through returns several things again happen:

1. The note is removed.
2. Its lost status is removed.
3. A credit is placed on the Patrons account.

This is a flawless system. We do not reimburse lost or overdue fines - just the replacement cost of the book.





---- Additional Comments From dschust1@gmail.com 2009-05-19 14:24:03 ----

(In reply to comment #5)
> How it currently works in Koha 2.2.9
> 
> A book is either marked lost by a staff member OR is marked lost by becoming
> long overdue.
> 
> Both instances generate an invoice for the replacement cost of the item in the
> Patron's account.
> 
> When the Patron pays that invoice several things happen:
> 
> 1. The invoice is marked paid.
> 2. The item is returned off the borrowers card.
> 3. Its lost status remains in place.
> 4. A note is generated which says "Paid for by <patrons barcode number> and the
> date.
> 
> Then, later when the lost book is returned or found, as it comes through
> returns several things again happen:
> 
> 1. The note is removed.
> 2. Its lost status is removed.
> 3. A credit is placed on the Patrons account.
> 
> This is a flawless system. We do not reimburse lost or overdue fines - just the
> replacement cost of the book.
****************************************
This is the functionality I am looking for. - dws.



---- Additional Comments From gmcharlt@gmail.com 2009-07-22 14:28:31 ----

For folks watching the patch stream, don't get too excited by Darrell's patch for 3230 - that's actually for http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3166.



---- Additional Comments From dschust1@gmail.com 2009-09-14 03:26:54 ----

(In reply to comment #7)
> For folks watching the patch stream, don't get too excited by Darrell's patch
> for 3230 - that's actually for http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3166.

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3265 - gets closer to this fix - it is creating the credit on the borrower account, but not changing the status to available.

New bug though is the credit on the account is not able to close to balance the borrowers account to Zero again without a manual invoice - which you then can't write off or pay because the credit remains - opening a new bug for this if I can't find one.  See http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3607.



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

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

Unknown operating system Windows 2000. Setting to default OS "All".
Actual time not defined. Setting to 0.0
CC member adrea@moablibrary.org does not have an account here
CC member joe.atzberger@liblime.com does not have an account here

Comment 1 Nicole C. Engard 2011-11-07 16:31:04 UTC
I believe this is fixed in 3.6. Please reopen if I'm wrong.