[OPEN-ILS-DEV] Fine Generation Code Question

[Galen Charlton]

Hi,

On Fri, Nov 21, 2014 at 10:48 AM, Dan Wells <dbw2 at calvin.edu> wrote:
> The main problem with plan #2 is not the generation component of fine
> handling, but all of the other possible alterations and adjustments to fines
> which can happen depending on the checkin conditions.  I do agree that #2 is
> better from a design perspective, but it is quite a bit more complex than
> your outline suggests, and it would (in my opinion) be much safer to
> approach that design iteratively, which is what I hope doing #1 first would
> allow us to do.

To toss in a use case to keep in mind, one of the things that I know
some Evergreen sites have run into is a need to keep the time
responding to a SIP2 checkin request short so as to not cause a sorter
to route an item to the exceptions bin.

For that use case, the sorter will need to know where the item goes
next, which means that processing to determine if the item fills a
hold request can't be deferred (although it perhaps could be
simplified in the interests of minimizing exceptions), but the sorter
wouldn't necessarily care about fine processing.

On the other hand, at the circ desk itself, fine processing during
checkin can't necessarily be delayed indefinitely, as a patron may
want to pay their fines right away, but a small delay between checkin
and reconciling the current fine state could be acceptable as long as
it were presented well in the UI.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org