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
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.grah...@herts.ac.uk
>
> ___
> Koha mailing list http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
