Grahm, This is an interesting question, and I'll be interested in seeing other library's answers to this... I suspect that it depends a great deal on the size of the library. One way around this would be to create a report showing a list of waiting holds, ordered by itemcallnumber, author and title SELECT itemcallnumber, author, title, barcode FROM reserves inner join bibio using (biblionumber) inner join items using (itemnumber) WHERE reserves.found = 'W' and reserves.waitingdate = CURRENT_DATE ORDER BY itemcallnumber, author, title This should be fairly close to the order that items would be in after sorting for shelving (if you use a different order for shelving, you can adjust the query accordingly), so it would be fairly quick to identify which items need to be pulled from the shelving cart. If you have the ReturnLog system preference set to LOG, the action_logs table contains a 'user' column that you could use to identify returns by the SIP user associated with the self check machine, which you could use to narrow the report above. --Barton On Wed, Oct 19, 2016 at 4:39 AM, Graham, Stephen <s.graham4@herts.ac.uk> wrote:
Hi All - we've only just implemented holds, we went live 3 weeks ago. One thing we are grappling with is books which have holds on, going "missing" before they get to the holds shelf. At the moment if a user returns an item via the Selfcheck machines,which is on hold for another user, then an email (informing the user that their book is ready to collect) is automatically added to the message_queue table and then sent when the email cronjob runs. However, the user may not actually place the returning item in the holds bin, they may put it on the normal return trolley, where some else may take it to read in the Library and then anything can happen to it. In cases like these the email has already been generated and the book is NOT ready to collect even though we've told the user that it is.
This is happening often at the moment, and we are dealing with it in two ways - either removing the user's email address from their record, so the email cannot be sent, or deleting the message from the table at the SQL level. Neither of these are ideal. I'm just wondering how other people are handling this? We have two campuses, and when an on-hold item is returned which is for a user at the other campus, it goes into transit and the email does not get generated until the item is checked in at the other campus. Can the same be achieved with the Selfcheck machines? Creating a separate virtual library, adding the self check machine users to it, and then books will automatically go into transit, therefore the email will not get generated? Do other libraries do this?
Cheers, Stephen Stephen Graham Library Technology Consultant Academic Resources Library and Computing Services University of Hertfordshire Hatfield AL10 9AB UK Tel. 01707 286111 Ext: 77751 Email s.graham4@herts.ac.uk
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha