Bug 5851 - SIP Slips printed in wrong circumstances -- Local hold and no hold items
Summary: SIP Slips printed in wrong circumstances -- Local hold and no hold items
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: 3.4
Hardware: All All
: P5 - low minor (vote)
Assignee: Colin Campbell
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-10 15:58 UTC by Liz Rea
Modified: 2017-12-07 22:17 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 Liz Rea 2011-03-10 15:58:16 UTC
Here is how we would like the check-in process to work in Koha on the SIP connection:

1) a WALKIN item type should never generate a hold slip (currently does)
2) a LOCALHOLD type should only generate a hold slip if there is an
unfilled hold for a local patron (currently does for any hold)
3) If a hold slip is generated for any valid circumstances...
     a) the item processed should be tied to the patron on the slip 
     b) the item should be in the proper status (hold should be confirmed and put in transit if necessary)

In summary, when a hold slip is generated we should be able to place
the slip in the item and put it in the courier or on our hold shelf.
Comment 1 Ian Walls 2011-03-21 16:56:56 UTC
The SIP code just calls AddReturn, which in turn consults CheckReserves, which does not respect the holds policies configued in the Circulation and Fines Rules area.
Comment 2 Katrin Fischer 2015-01-06 18:04:17 UTC
Liz, can you tell if this is still valid for master?
Comment 3 Katrin Fischer 2016-08-14 19:42:46 UTC
I am a bit confused by this:
print slip = set a hold waiting/triggering a hold?

I suspect this has been fixed since, but it's hard to tell without more information.
Comment 4 Katrin Fischer 2017-01-04 10:05:17 UTC
There is not enough information here to make it possible to reproduce the problem.