Bug 20626

Summary: Fines are recalculated and removed on SIP checkin
Product: Koha Reporter: Stefan Berndtsson <stefan.berndtsson>
Component: SIP2Assignee: Bugs List <koha-bugs>
Status: CLOSED WORKSFORME QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: colin.campbell, martin.renvoize
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 10694    
Bug Blocks:    

Description Stefan Berndtsson 2018-04-20 10:09:18 UTC
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.
Comment 1 Martin Renvoize (ashimema) 2020-02-06 09:30:02 UTC
I believe this was fixed as part of bug 14591