[OPEN-ILS-DEV] Lost item handling

[Bill Ott]

Before we're completely buried in snow, I thought I'd show my work and 
get some initial comments. 

> Short story:
> 1)  "void lost on checkin" is in the works (but see below)
> 2) maybe? ;)  depends on what you're looking for
> 3) they generally are, however, I have an opinion about the
> circ.lost_immediately_available setting
>   

I'm actually surprised there is a short story. ;-)

> Less-short story:
> "Void lost on checkin" can mean a few different things.  There are
> normally two different generated charges, lost processing fee and lost
> replacement charge, and either one or both might need to stick around
> depending on circumstances.  So, that's part of what is being taken
> into account with the "in the works" support, based on a (relatively
> speaking) wide range of input from production sites (including, in
> fact, one of your MLC compatriots ;) ).
>   

I realized that.  In the code I've been playing with, I added pieces for 
both.  Actually a 3rd, as we (GRPL) go as far as removing the lost 
charge, but reinstate the original overdue fines.  So I've got a piece 
that reinstates the original overdue charges, un-voids them essentially.


> More generally, dealing with the design of this class of setting
> (automatic money stuff) is complicated by the fact that the
> circulating location (where the LOST circ is attached to) is not
> necessarily the correct context org unit for the setting -- you want
> these settings attached to the owner of the item, not the transaction,
> because it's the owner that needs to recoup the cost of a lost item.
> In some consortia (those with a higher policy-barrier to sharing) this
> won't matter in practice, but for others (low or no policy-barrier to
> sharing) it will be very important.  The issue is that this presents a
> (seemingly arbitrary) staff workflow change -- for instance, some
> items will be immediately available or have processing fees removed
> (or not, on either or both).  It's something that can smoothed over
> with policy, but I would like to see what we can come up with
> technologically to help.
>   

I am using copy->circ_lib for each, although that certainly isn't 
obvious from the setting name.


> In any case, please send patches early and often, and we will review
> and give feedback as quickly as possible.  Since this is touching some
> of the most complicated biz logic that's directly embedded in the
> middle layer code we'll want to increase the communication loop
> significantly, to make sure that you're code gets in as quickly and
> smoothly as possible.
>   

Again, showing what I've done quick-n-dirty.  It's also only against 
1.2.4, as I don't have all my other goodies merged into 1.4 yet, but for 
what it's worth...



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Circulate.pm.diff
Type: text/x-patch
Size: 4652 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081219/6112cfbb/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Const.pm.diff
Type: text/x-patch
Size: 981 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081219/6112cfbb/attachment-0001.bin