Bug 20626 - Fines are recalculated and removed on SIP checkin
Summary: Fines are recalculated and removed on SIP checkin
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 10694
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-20 10:09 UTC by Stefan Berndtsson
Modified: 2020-11-30 21:45 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 2020-02-06 09:30:02 UTC
I believe this was fixed as part of bug 14591