This bug depends on Bug 13482, which fixes information being printed on the RESERVESLIP on first scan. Before, not all information was being populated on the slip after the first scan for holds being sent to another library. Now, information is always populated, but I have found the items.holdingbranch to be holding the incorrect value on the first scan. When you scan the item a seconde time, the value is correct. To reproduce problem: 1) Include the items.holdingbranch field on the RESERVESLIP. 2) Place a hold on an item to be picked up at a different branch. 3) Check in the item and print the slip. Notice that the items.holdingbranch field is populated with the library the item is being sent to, not your library. 4) Check in the item again and print the slip again. Notice now that the items.holdingbranch field is populated with the library the item is being scanned at (the correct location). Christopher
What I think is going on is the following: 1) The "print slip, confirm and transfer" button it clicked 2) The item is transferred, this act updates the holdingbranch to the destination branchcode for the item 3) The data is gathered and the slip is printed <-- This is why the branch is "wrong" 4) Rescanning the item triggers and update of the holdingbranch again and sets it to your branchcode 5) Reprinting the slip now makes it look "correct" but has possibly screwed up the transfer and the item needs transferred again ( or possibly the holdingbranch is updated a second time later on in step 4 after the data is gathered for the slip )
So, Kyle, are you saying that scanning the item a 2nd time messes up the transfer? I have seen no evidence of that, and it shouldn't. The process works as expected. It is just the holding branch that appears to be incorrect. But it sounds like you are saying it really isn't incorrect until it is scanned and printed again. Am I understanding that correctly?
Would like to see further discussion or follow-up on this bug. Christopher
I think it has been fixed by bug 24612, can you confirm? *** This bug has been marked as a duplicate of bug 24612 ***