Hi, On Fri, Nov 21, 2014 at 10:48 AM, Dan Wells <[email protected]> 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: [email protected] 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
