You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Swapnil Shah (JIRA)" <ji...@apache.org> on 2014/11/28 11:27:12 UTC

[jira] [Comment Edited] (OFBIZ-5364) Incorrect quantityNotAvailable for OrderItemShipGrpInvRes when issuing items to shipments

    [ https://issues.apache.org/jira/browse/OFBIZ-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228203#comment-14228203 ] 

Swapnil Shah edited comment on OFBIZ-5364 at 11/28/14 10:26 AM:
----------------------------------------------------------------

[~ofbizzer] In first place i am not sure how idealistic is the scenario for enabling more issuance than what is reserved within any ship group Bit still If AT ALL we are allowing this then the issue seems to me is in step#9. As the user is directly allowed to ship/issue the material reserved from any given ship group to any different ship group then corresponding OISGIR per each ship group should be updated accordingly. In other words if we extend your given use case then following happened:
# In step#7 when 1 unit is received then following was the OISGIR state (say your order Id is 10000):
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 49 |
| 10000 | 00002 | 00001| 50 | 50 |
# In step#9 when 1 unit was issued from second ship group (which is still reserved against first ship group) then OISGIR changed as follows:
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 49 |
| 10000 | 00002 | 00001| 49 | 50 |
# And possibly due to this in step#10 you are still seeing issue qty text box showing 1 because i think it shows issue=OISGIR.QUANTITY  - OISGIR. QUANTITY_NOT_AVAILABLE. But in reality its all messed up because now reservations against both ship group are corrupted.

The expected result after step#9 should be as follows in OISGIR as we transferred the reservations from first ship group to second in the process and eventually ended up with issuance from second ship group.
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 50 |
| 10000 | 00002 | 00001| 49 | 49 |

I hope it should resolve the issue. Lemme know if i missed anything.  


was (Author: swash78):
[~ofbizzer] The issue seems to me in step#9. If at all we are allowing the user to directly ship/issue the material reserved from any given ship group to any different ship group then corresponding OISGIR per each ship group should be updated accordingly. In other words if we extend your given use case then following happened:
# In step#7 when 1 unit is received then following was the OISGIR state (say your order Id is 10000):
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 49 |
| 10000 | 00002 | 00001| 50 | 50 |
# In step#9 when 1 unit was issued from second ship group (which is still reserved against first ship group) then OISGIR changed as follows:
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 49 |
| 10000 | 00002 | 00001| 49 | 50 |
# And possibly due to this in step#10 you are still seeing issue qty text box showing 1 because i think it shows issue=OISGIR.QUANTITY  - OISGIR. QUANTITY_NOT_AVAILABLE. But in reality its all messed up because now reservations against both ship group are corrupted.

The expected result after step#9 should be as follows in OISGIR as we transferred the reservations from first ship group to second in the process and eventually ended up with issuance from second ship group.
|| ORDER_ID ||	SHIP_GROUP_SEQ_ID ||	ORDER_ITEM_SEQ_ID || QUANTITY || QUANTITY_NOT_AVAILABLE ||
| 10000 | 00001 | 00001| 50 | 50 |
| 10000 | 00002 | 00001| 49 | 49 |

I hope it should resolve the issue. Lemme know if i missed anything.  

> Incorrect quantityNotAvailable for OrderItemShipGrpInvRes when issuing items to shipments
> -----------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-5364
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5364
>             Project: OFBiz
>          Issue Type: Bug
>          Components: order
>    Affects Versions: Release Branch 12.04
>            Reporter: Christian Carlow
>
> The quantityNotAvailable field of OrderItemShipGrpRes seems to reflect incorrect numbers after shipment issuances occur.
> To reproduct:
> 1.  Create an order for DemoCustCompany for a quantity of 100 of a product having no inventory quantity 
> 2.  Create a second ship group on the Shipping page
> 3.  Assign half of the order item quantity (50) to the second ship group created and then finish creating the order
> 4.  Click the "New Shipment for Ship Group" button for the first ship group and navigate to the "Order Items" page
> 5.  On the "Order Items" page, notice the issue quantity field is blank because no inventory exist yet to be issued to the shipment.  
> 6.  Navigate to the WebstoreWarehouse Receive Inventory page and receive a quantity of 1 for the order item product to increase the inventory by 1
> 7.  Refresh the Shipment Order Items page and you'll see the issue quantity change to 1 because the inventoryItemId created in the last step was assigned to the orderItemShipGrpInvRes for this item.
> 8.  Now change from ship group 00001 to ship group 00002 and notice the issue quantity is blank
> 9.  Assign a quantity of 1 to the second ship group and click the "Issue All" button
> 10.  Change the ship group back to 00001 and notice the quantity in the issue text box is still 1
> It seems like the issue text box in step 10 should be 0 instead of 1 since the inventory item quantity was used for ship group 2.  
> Does anyone disagree?  Could I be misinterpreting the way the OrderItemShipGrpInvRes is supposed to work?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)