https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37625
--- Comment #3 from Alexander Wagner <[email protected]> --- > 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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
