PacksToShip changes its value

Description

When I initiate some requisition, value of packsToShip for product is equals to 1. When I submit my requisition, the value is changed to 0. Then I authorize my requisition and the value of packsToShip is changed again to 1.

  • submitted requisition

  • authorized requisition

Acceptance Criteria:

  • packsToShip should be always the same

  • Total Cost should be calculated based on packsToShip

  • when requisition is/is not emergency and submitted/authorized/approved/converted to order, value of packsToShip is untouched

Environment

None

Attachments

3

QAlity Plus - Test Management

Checklists

Activity

Klaudia Pałkowska 
February 3, 2017 at 11:13 AM

I found diagram which shows columns dependencies and it looks like for requisition with status AUTHORIZE/APPROVE packsToShip is calculated from approvedQuantity, not requestedQuantity. So approvedQuantity value 0 is the cause of displaying packsToShip as 0.

Anna Czyrko 
February 3, 2017 at 10:03 AM

I retest this ticket (clean cache):
1. I initiate requisition with id: 6167e65c-6f56-4aeb-bff5-fdfe84e01a21 (from demo data)
2. I have some values in Packs To Ship column: for C400 = 23, C600=96, C100=1, C200=1, I submit requisition, I have that same values in Packs To ship column.
3. I authorize requsition, all values in Packs to ship column have value 0. I can change this value when I enter some data in Approved quantity column.
4. I cannot approve requisition to check if new value is added, because i have error when I click Approve button.

Klaudia Pałkowska 
February 3, 2017 at 7:47 AM

I can't reproduce this issue. Can you check it again? Maybe you should clear cache?

Anna Czyrko 
February 2, 2017 at 2:13 PM

for submitt all works, but problems occur when I authorize a requisition

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Original estimate

Time tracking

4h logged

Components

Sprint

Fix versions

Priority

Time Assistant

Created January 9, 2017 at 9:05 AM
Updated February 3, 2017 at 2:15 PM
Resolved February 3, 2017 at 1:14 PM