Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5364

Incorrect quantityNotAvailable for OrderItemShipGrpInvRes when issuing items to shipments

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Release Branch 12.04
    • Fix Version/s: 14.12.01, 16.11.01
    • Component/s: order
    • Labels:
      None

      Description

      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?

      1. OFBIZ-5364.patch
        3 kB
        Divesh Dutta
      2. OFBIZ-5364-1.patch
        1 kB
        youssef khaye

        Activity

        Hide
        swash78 Swapnil Shah added a comment - - edited

        Christian Carlow 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:

        1. 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
        2. 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
        3. 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.

        Show
        swash78 Swapnil Shah added a comment - - edited Christian Carlow 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.
        Hide
        diveshdut Divesh Dutta added a comment -

        Christian ,

        The issue you reported is right and it exists . Also thanks to Swapnil for giving the detailed analysis on where things are going wrong. Just so every one know, I am working on fix of this issue.

        Show
        diveshdut Divesh Dutta added a comment - Christian , The issue you reported is right and it exists . Also thanks to Swapnil for giving the detailed analysis on where things are going wrong. Just so every one know, I am working on fix of this issue.
        Hide
        diveshdut Divesh Dutta added a comment -

        Here is the attached patch which will fix this issue. So once the items are issued from one ship group to another, item issuance are created, OrderItemShipGrpInvRes is updated with new quantity and inventoryItemDetail records are updated. After all this we have cancelled reservations of respective OrderItemShipGrpInvRes and re-reserved it. Doing this will balance reservations in respective OrderItemShipGrpInvRes .

        Show
        diveshdut Divesh Dutta added a comment - Here is the attached patch which will fix this issue. So once the items are issued from one ship group to another, item issuance are created, OrderItemShipGrpInvRes is updated with new quantity and inventoryItemDetail records are updated. After all this we have cancelled reservations of respective OrderItemShipGrpInvRes and re-reserved it. Doing this will balance reservations in respective OrderItemShipGrpInvRes .
        Hide
        toashishvijay Ashish Vijaywargiya added a comment -

        Thanks Christian for creating the jira issue. Thanks Swapnil for providing the additional details, Thanks Divesh for the patch. For now I have committed changes in trunk(r1649405) and in Branch14.12(r1649408). For now I am keeping this issue open, will cross check this issue in R13.07 and if it does exists there then I will back port the changes over there as well.

        Show
        toashishvijay Ashish Vijaywargiya added a comment - Thanks Christian for creating the jira issue. Thanks Swapnil for providing the additional details, Thanks Divesh for the patch. For now I have committed changes in trunk(r1649405) and in Branch14.12(r1649408). For now I am keeping this issue open, will cross check this issue in R13.07 and if it does exists there then I will back port the changes over there as well.
        Hide
        diveshdut Divesh Dutta added a comment -

        This fix should be pushed to R13.07 as well. Thanks Ashish for committing the patch in in trunk and in Branch14.12

        Show
        diveshdut Divesh Dutta added a comment - This fix should be pushed to R13.07 as well. Thanks Ashish for committing the patch in in trunk and in Branch14.12
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        This does not pass tests, http://ci.apache.org/projects/ofbiz/logs/trunk/html/ I take over...

        Show
        jacques.le.roux Jacques Le Roux added a comment - This does not pass tests, http://ci.apache.org/projects/ofbiz/logs/trunk/html/ I take over...
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        orderHeader.originFacilityId might be empty

        Show
        jacques.le.roux Jacques Le Roux added a comment - orderHeader.originFacilityId might be empty
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Ashish Vijaywargiya I reassign to you, I tested, reverting the commit removes the test issue.

        Show
        jacques.le.roux Jacques Le Roux added a comment - Ashish Vijaywargiya I reassign to you, I tested, reverting the commit removes the test issue.
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        I will revert from R14.12 only for now...

        Show
        jacques.le.roux Jacques Le Roux added a comment - I will revert from R14.12 only for now...
        Hide
        jacques.le.roux Jacques Le Roux added a comment - - edited

        I reverted r1649408 at r1649549. I will soon add the tests for R14.12 on Buildbot...

        Show
        jacques.le.roux Jacques Le Roux added a comment - - edited I reverted r1649408 at r1649549. I will soon add the tests for R14.12 on Buildbot...
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        I have temporary removed (commented out) the testMultipleInventoryItemIssuance test after r1649408 and r1650455 in trunk at r1653056

        Show
        jacques.le.roux Jacques Le Roux added a comment - I have temporary removed (commented out) the testMultipleInventoryItemIssuance test after r1649408 and r1650455 in trunk at r1653056
        Hide
        lyoussef youssef khaye added a comment -

        I'am trying to fix the testMultipleInventoryItemIssuance test failure and i came across current Issue.

        I'am not so good at business rule, But I don't think we have the good solution for this Issue ( cancel OISGIR and recreate theme).

        This issue occurs when we issue an inventory item from one ship group to another ship group

        To fix this I suggest to add the ineventoryItemId when selecting OISGIRs to cancel & reserve

        look to attached patch OFBIZ-5364-1.patch

        Show
        lyoussef youssef khaye added a comment - I'am trying to fix the testMultipleInventoryItemIssuance test failure and i came across current Issue. I'am not so good at business rule, But I don't think we have the good solution for this Issue ( cancel OISGIR and recreate theme). This issue occurs when we issue an inventory item from one ship group to another ship group To fix this I suggest to add the ineventoryItemId when selecting OISGIRs to cancel & reserve look to attached patch OFBIZ-5364 -1.patch
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Hi Youssef,

        Did your patch fixes the testMultipleInventoryItemIssuance test failure?

        Show
        jacques.le.roux Jacques Le Roux added a comment - Hi Youssef, Did your patch fixes the testMultipleInventoryItemIssuance test failure?
        Hide
        jacques.le.roux Jacques Le Roux added a comment - - edited

        I received Youseef's answer by mail, in French. Here is the translation.

        Good evening Jacques;
        I do not know when I will have access to JIRA, I live answers you and apologize!

        The answer is yes, this patch fixes the problem from a functional point of view and consequently the JUnit test in question.

        In fact, functionally speaking, I think the previous patch is not good in measure or it does not take into account that an OrderItem might use several lines of stock InventoryItem.
        orderId orderItemSeqId orderItemShipGrpSeqId InvetoryItemId
        10000 000001 10000 000001
        10000 000001 10001 000001

        So by making a stock exit (ItemIssuance) we can afford to cancel the reservation lines for the line of stock in question but not all the lines of stock.
        That's why I added the lines in the inventoryItemId research question and then cancel a reservation!

        I think I'm clear.

        Thank you and sorry again for my email.

        Show
        jacques.le.roux Jacques Le Roux added a comment - - edited I received Youseef's answer by mail, in French. Here is the translation. Good evening Jacques; I do not know when I will have access to JIRA, I live answers you and apologize! The answer is yes, this patch fixes the problem from a functional point of view and consequently the JUnit test in question. In fact, functionally speaking, I think the previous patch is not good in measure or it does not take into account that an OrderItem might use several lines of stock InventoryItem. orderId orderItemSeqId orderItemShipGrpSeqId InvetoryItemId 10000 000001 10000 000001 10000 000001 10001 000001 So by making a stock exit (ItemIssuance) we can afford to cancel the reservation lines for the line of stock in question but not all the lines of stock. That's why I added the lines in the inventoryItemId research question and then cancel a reservation! I think I'm clear. Thank you and sorry again for my email.
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Thanks to Youseef's patch,

        This is fixed in
        trunk r1656185
        R14.12 r1656187

        Show
        jacques.le.roux Jacques Le Roux added a comment - Thanks to Youseef's patch, This is fixed in trunk r1656185 R14.12 r1656187

          People

          • Assignee:
            jacques.le.roux Jacques Le Roux
            Reporter:
            ofbizzer Christian Carlow
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development