Bug 14099 - RESERVESLIP shows incorrect information in items.holdingbranch on first scan
Summary: RESERVESLIP shows incorrect information in items.holdingbranch on first scan
Status: RESOLVED DUPLICATE of bug 24612
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 13482
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-30 15:29 UTC by Christopher Brannon
Modified: 2020-08-06 10:13 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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 ***