Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Date: Sat, 20 Sep 2014 13:12:33 +0000 (UTC)
From: "Divesh Dutta (JIRA)" <jira@apache.org>
To: dev@ofbiz.apache.org
Message-ID: <JIRA.12675307.1382552777000.86109.1411218753718@Atlassian.JIRA>
In-Reply-To: <JIRA.12675307.1382552777000@Atlassian.JIRA>
References: <JIRA.12675307.1382552777000@Atlassian.JIRA>
 <JIRA.12675307.1382552777493@arcas>
Subject: [jira] [Updated] (OFBIZ-5370) OrderItemShipGrpInvRes incorrect when
 receiving an inventory item that relates to more than one record
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OFBIZ-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divesh Dutta updated OFBIZ-5370:
--------------------------------
    Attachment: OFBIZ-5370-trunk.patch

Issue is in balanceInventoryItems service. This service pulls up order items which already have  sufficient inventory for doing re-assignments of reservations. It should not pull order items which already have all the required inventory reservations.  Also reassignInventoryReservations services does the same job in a better way.

 So instead fixing in balanceInventoryItems service we are calling reassignInventoryReservations from balanceInventoryItems service. This is one step forward towards code clean up. In future, we can delete balanceInventoryItems and replace it with reassignInventoryReservations every where. 

> OrderItemShipGrpInvRes incorrect when receiving an inventory item that relates to more than one record
> ------------------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-5370
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5370
>             Project: OFBiz
>          Issue Type: Bug
>          Components: order
>    Affects Versions: Release Branch 12.04
>            Reporter: Christian Carlow
>         Attachments: OFBIZ-5370-trunk.patch
>
>
> OrderItemShipGrpInv records that share the same inventoryItemId calculate incorrect results when receiving inventory for the product.
> To reproduce:
> 1.  Create an order for product "PEPPERS-G" with a quantity of 10 and click "Finish Order"
> 2.  Add another ship group and click "Continue"
> 3.  Assign 5 of the order items to the second ship group created and then finish the order
> 4.  Navigate to the Receive Inventory page of the WebStoreWarehouse facility
> 5.  Enter "PEPPERS-G" into the productId field and click "Receive Product"
> 6.  Enter a quantity of 6 into the quantityAccepted field and click "Receive"
> 7.  Open the OrderItemShipGrpInvRes table and notice that the quantityNotAvailable field has been set to blank for the first record and 4 for the second record and that they both share the same inventoryItemId
> 8.  Now navigate back to the Receive Items page and receive in the product again but with a quantity of 1
> 9.  Refresh the OrderItemShipGrpInvRes results and notice that the first record has a new inventory item applied to it with a quantity of 1 and the other record has been updated to reflect a new quantityNotAvailable value.
> It seems like OrderItemShipGrpInvRes should be deleted anytime the quantityNotAvailable field gets set to 0, blank, or null.  I've noticed this logic performed in other methods that deal the entity.
> Step 9 should not add quantityNotAvailable back to the first record one it has been fulfilled.  The second item was supposed to have its quantityNotAvailable field decremented by 1 but no change took plce for it. 
> I believe this problem is probably caused by an inventoryItemId being associated with more than one record in the table.
> This problem basically happens anytime the inventory received is greater than the quantityNotAvailable field of the first OrderItemShipGrpRes table.  It happens when you have orders from two different customers and you receive more inventory than the quantityNotAvailable for the first customer order item.


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