| Summary: | Update HoldsNeedProcessingSIP system preference description | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
| Component: | System Administration | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | alexander.wagner, gmcharlt |
| Version: | Main | Keywords: | Academy |
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Katrin Fischer
2024-08-13 14:00:52 UTC
Furthermore, one should also note here, that with `HoldsNeedProcessingSIP` set to `don't fulfill` items can not be promoted from `in preparation` to `waiting` by another SIP checkin. It seems that the second check in has to be performed from the Intranet only, as SIP checkins do not promote the items like regular check ins, but just set a fixed status. (Unfortunately.) Sidenote: for a newbe like me the term `fulfill` was not really self explanatory in this context here as it referred only to the library having the item. I think the fact that it doesn't work to move from processing to waiting via SIP2 is fully intentional. But documentation would be good, I agree. The idea here is that the email to inform about pick-up is not sent, until the item is handled at the circulation desk. Then the second check-in there fulfills the hold, triggers the email etc. > The idea here is that the email to inform about pick-up is not sent, until the item is handled at the circulation desk.> Then the second check-in there fulfills the hold, triggers the email etc. I understood that second check in. We have to get used to the ILS popping up modals all the time as the means to initiate some functions, though. We currently use SIP as _the way_ to check in and out items. We hardly ever use any desk operations. Even if I have the patron at the desk to fetch her hold we walk over to the SIP terminal for the actual check out. (The patron barcode at the ready on the slip ;) So, I was imagining that I could set `HoldsNeedProcessingSIP`, I fetch the item from the cart, place it on the SIP terminal right next to it and I then end up in the fulfill state to send notifications an print slips from the desk. Koha does quite some magic here that we are used to do by explicit check _outs_ to a card. We e.g. SIP check out to "transport" or to "ready for pick up" depending on what we have. The barcode necessary for checkout gives the additional parameter we don't have at check in. We'll adopt our procedures accordingly. It might be even advantageous as we check in every item from the cart again. (Quite a few of our patrons tend to place them in the cart _without_ returning them first.) BTW: there is a similar behaviour, where Koha does not move on but sets a state is described in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37428 |