Simon Read
My feedback
32 results found
-
41 votesSimon Read
shared this idea
·
-
162 votesSimon Read
supported this idea
·
An error occurred while saving the comment -
36 votesSimon Read
supported this idea
·
-
44 votesSimon Read
supported this idea
·
-
105 votesSimon Read
shared this idea
·
-
118 votesSimon Read
supported this idea
·
-
54 votesSimon Read
shared this idea
·
-
54 votes
An error occurred while saving the comment Simon Read
commented
Thanks Moshe,
We have logged a couple of cases in the past (167336 and 57810). For 57810 we got told to use scan in items and if we wanted it to work for return items that we should submit an enhancement/ideas exchange hence this post. Subsequently that decision has been reversed and some additional development has been committed to.
We hate having to say to staff they should use scan in items for some things and return items for others so we say to staff they should scan an item through return items to determine next steps. This almost always works but there have been a couple of exceptions in the past.
Any other voters for this request like to add an area where return items doesn't fill your needs and you have to use scan in items instead?
Simon
An error occurred while saving the comment Simon Read
commented
An example of where this causes us problems is with the return of on loan items that have a Home Delivery request on them.
All loans are processed through Return Items to determine next steps - in the case of an item with a Home Delivery Request no Home Delivery slip prints. If, however, the item is scanned in via Scan in Items the Home Delivery slip is printed - this is counter intuitive as staff don't know which items have Home Delivery requests on them so they don't know they should scan them in via Scan in Items. It is very confusing for staff.
Simon Read
shared this idea
·
-
47 votesSimon Read
shared this idea
·
-
14 votesSimon Read
shared this idea
·
-
96 votes
An error occurred while saving the comment Simon Read
commented
Currently the patron purge functionality works based on the purge date.
It would be nice if there was an option to choose to use the expiry date rather than the purge date - we find that staff often forget to change the purge date when they extend the expiry date for patrons so using the expiry date would be more reliable.
Simon Read
supported this idea
·
-
93 votesSimon Read
supported this idea
·
We're in a similar position where we wish to enable specific locations in a Library to be able to be picked up at a Library (or libraries) that we define but the current rules just aren't granular enough for us to be able to do that. We've looked at the relationship rules but they define what happens at the Library rather than location level.
Like Aya we'd like to have another pickup location rule added in the TOU that would allow us to specific which libraries could be selected for pickup