Developers: We had a few questions about the waitingreserves.pl report. Of course the scenario is specific to our consortium but wanted to get your take on it. 1. The location displayed in the ACTION column when canceling a 'hold over' item is the item's home library; but often, there is a hold on the item for another library (not the home library). It is the next library in the holds queue that should display in this column, rather than the item home location. 2. Canceling the 'hold over' from waitingreserves.pl should trigger a transit prompt, instructing the staff person to send the item on to the hold library, if a hold exists on the item. This doesn't happen. Nothing happens when the 'hold over' is canceled. A staff person, seeing the information displayed in the ACTION column, would naturally assume that the item is to return to its home library. So, regardless of whether a hold exists, the 'hold over' canceled item is being returned home. We have found that a hold transit prompt will trigger if the canceled hold item is checked in after it is canceled. But this is a two-step process that we have not yet trained any of our libraries to perform, as we just discovered this issue. We are seeing lots of problems associated with this, since many hold items are being sent back to their home locations, instead of their next hold location. Attached is a screen shot illustrating the issue. The cancel hold item, TWILIGHT, has a long hold list, but the instructions say to return the item to its home location, MCLOUTH. It should actually go to NORTONVILLE to fill the next hold on the list, as illustrated in the second screen shot, which is the transit prompt that only displays if the item is Checked In. Is this an area where development will need to be sponsored, or is it a known issue/bug? I looked and was unable to find anything on it in bugzilla, so apologies if I missed it. Thanks for your time and efforts and for putting out a great product Liz Rea NEKLS