https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37625 Alexander Wagner <alexander.wagner@desy.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexander.wagner@desy.de --- Comment #1 from Alexander Wagner <alexander.wagner@desy.de> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37625 --- Comment #3 from Alexander Wagner <alexander.wagner@desy.de> ---

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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.