Bug 14099

Summary: RESERVESLIP shows incorrect information in items.holdingbranch on first scan
Product: Koha Reporter: Christopher Brannon <cbrannon>
Component: Hold requestsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: george, gmcharlt, jonathan.druart, kyle, nick, veron
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 13482    
Bug Blocks:    

Description Christopher Brannon 2015-04-30 15:29:43 UTC
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
Comment 1 Kyle M Hall (khall) 2015-05-04 17:52:15 UTC
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 )
Comment 2 Christopher Brannon 2015-05-11 22:32:47 UTC
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?
Comment 3 Christopher Brannon 2016-02-26 19:32:54 UTC
Would like to see further discussion or follow-up on this bug.

Christopher
Comment 4 Jonathan Druart 2020-08-06 10:13:10 UTC
I think it has been fixed by bug 24612, can you confirm?

*** This bug has been marked as a duplicate of bug 24612 ***