[Koha-bugs] [Bug 20626] New: Fines are recalculated and removed on SIP checkin

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

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

            Bug ID: 20626
           Summary: Fines are recalculated and removed on SIP checkin
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: SIP2
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: stefan.berndtsson at ub.gu.se
        QA Contact: testopia at bugs.koha-community.org
                CC: colin.campbell at ptfs-europe.com

When a patron has an accruing fine (code FU) for an item, and that item is
returned, there are some parts of the logic that causes unexpected
consequences.

All of the following assumes CalculateFinesOnReturn is not active.

The following happens when the issuing rule fine value is set to 0.

If the return is made via the staff interface, and no explicit return date is
set, the item is returned, and the fine is changed to code F, but amount
remains.

If the return is made via the staff interface, with an explicit return date,
the item is returned, and the fine is changed to code F, but the amount is
cleared. This is documented in a comment in the code as the expected behaviour.

If the return is made via the SIP2 protocol, it will always have an explicit
return date, because the date is set from the SIP reply. Therefor the amount
will be cleared. This is unexpected since the SIP checkins aren't backdated
returns.


When the issuing rule fine value is set to higher than 0, similar things
happen, except it will change the fine instead of clearing it. Again, this is
unexpected for SIP checkin. With no expected backdating, and
CalculateFinesOnReturn disabled, I'd expect fine amounts to remain untouched.

A very simple fix is of course to change C4/SIP/ILS/Transaction/Checkin.pm and
simply not send $return_date to AddReturn(). I don't know if this is a proper
solution or not.

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