[Koha-bugs] [Bug 23091] Add options to charge new or restore forgiven overdues when a lost item is returned

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23091

--- Comment #41 from Martin Renvoize <martin.renvoize at ptfs-europe.com> ---
(In reply to Andrew Fuerste-Henry from comment #40)
> > There's soooo many syspref interactions at
> > play here I hadn't fully appreciated when I embarked down this path.
> 
> And I very much thank you for walking this scary path through the foreboding
> wood!
> 
> > Also, a question for you.. what should happen in the case where they have
> > the system set to not forgive fines and to also charge a fresh fine on
> > return of a lost item.. if feels like a mis-configuration at that point to
> > me but should we catch that case and just fallback to doing nothing or
> > should we niavely continue to charge a fresh fine on top so the patron would
> > end up with two fines.. one dated up to the date when the item was marked
> > lost and then a second dated up to the date it was marked found again?
> 
> That is a very good question. I'd say if WhenLostForgiveFines is set to not
> forgive then we don't do anything to overdues when a lost item is returned.
> If the initial overdue fine was never forgiven, then we don't make a new
> overdue fine or touch/edit the existing overdue if the item is later
> returned.
> 
> I hate to say it, but that sort of points me toward thinking these new
> options should live in WhenLostForgiveFine rather than in the lost item fee
> refund on return policy. That'd mean lost item fee refund on return policy
> stays with the existing yes/no options and WhenLostForgiveFine changes to
> four options: Don't forgive, Forgive permanently, Forgive but restore fine
> if item found, Forgive but create new fine if item found.
> 
> But please ignore that last paragraph if you feel you're too far along with
> your current approach. You asked a question that really shifted some stuff
> in my thinking on this.

Damn.. the existing preference levels are so inconsistent :(

WhenLostChargeReplacementFee is set at the system wide level, yet RefundLostFee
is set at the branch level.. that doesn't make much sense to me.. surely if one
allows granular control, so should the other..  I'm almost inclined to go the
opposite way from your suggestion and work through moving some of those system
policies into the circ rules to allow more granular control (Likely in a bug
for each, rather than inline here) to make them self-consistent. You can still
get the same overall functionality by only setting them at the default level
and not adding overridden rules at the branch level as we do now for the Refund
policy.  (In my mind, I'm looking at consortia and thinking the more granular
we get for them the better.)

-- 
You are receiving this mail because:
You are watching all bug changes.