Bug ID: 22373
Summary: Stock Rotation duration test
Change sponsored?: ---
Priority: P5 - low
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] Target Milestone: ---
It looks like this uses the branchtransfers column datearrived to check for
duration. Does that mean if an item goes on hold to another branch and then is
returned, the duration for that item is reset to be the the full duration
>>Comment # 371 on bug 11897 from Martin Renvoize
>>Must admit, my recollection of this code is somewhat vague... But, I believe
>>the combination of home branch with the date fields prevents that particular
>>issue. However, it would be nice to have a test to prove that hypothesis..
>>might be worth opening another bug for that?
Per Martin's comment above, can we test to see if an item goes on hold to
another branch and then is returned does the duration get reset based on the
last date that item arrived at its home branch.
--- Comment #1 from Lisette Scheer <[hidden email]> ---
It does appear to have reset when it arrived back at home branch.
Placed an item in a rota 4/17/2019 (Duration 20 days)
Arrived at new home 4/18/2019 (Day 0)
Hold found and sent to another branch 4/24/2019 (Day 6)
Hold filled, checked out, returned to home branch 4/26/2019 (Day 8/Day 0)
5/8/2019 should have been Day 20. As of 5/9/2019 it has not moved forward.
I will check again on 5/17/2019 to make sure it moves on.
--- Comment #3 from Lisette Scheer <[hidden email]> ---
After this I went and looked at the code and it looks like it needs to be on
the shelf for 20 days at the branch (in a row I think) for it to move on when
the cronjob runs.
What we were hoping for with the stock rotation was more like this:
June 1, Rota moves from MOS to BOV set to be there for 120 days.
September 29, Rota moves from BOV to DEA set to be there for 120 days.
Doesn't care if it was checked out during that time, on the shelf, in transit