[OPEN-ILS-DEV] Lost item handling

[Mike Rylander]

On Wed, Dec 17, 2008 at 10:45 AM, Bill Ott <bott at grpl.org> wrote:
> In researching some options for handling our billing of lost items, I was
> delighted to find the 'circ.void_overdue_on_lost' setting.
>
> I was going to develop a couple similar options, such as:
>  'circ.void_lost_on_checkin', to remove lost charges if an item was
> subsequently returned (perhaps based on date)
>  'circ.restore_overdue_on_lost_return', to restore the overdue charges that
> are voided by 'circ.void_overdue_on_lost'
>  'circ.lost_immediately_available', to avoid having lost items travel to
> their owning location before being circulated again
>
> Somewhat thinking out loud there, but I 1.) wanted to see if I was
> duplicating anyone's efforts, 2.) find out if there were other settings I
> just hadn't discovered yet, and 3.) make sure that the org_unit_settings
> were the preferred method to implement these sort of features.
>

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

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

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.

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.

Thanks, Bill, and I can't wait to see some biz logic patches and
contributed features.  That's a big step for the project, IMO.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com