Packing using backorder reservations?

[Paul Foxworthy]

Hi all,

Please have a look at the code at
https://github.com/apache/ofbiz/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/shipment/packing/PackingSession.java#L132

I have been testing a situation where there are three serialized items in
stock, and three on back order. So there are four reservations
(OrderItemShipGrpInvRes instances), and four inventory items: one for each
of the serialized items in stock, and one more for the back order.

While packing, the code here is looking for a reservation or reservations
for the order, in descending order of quantity. So it finds the back order
reservation first, and proceeds to use it and its associated inventory item
(with zero QOH and negative ATP) for the shipment, which is stupid.

I think that the code at this point should only look for
OrderItemShipGrpInvRes instances where the quantity exceeds the
quantityNotAvailable, and should only allocate to packing the difference
between the two, and not the full quantity.

I think the problem is not unique to serialized inventory items, but these
will exacerbate the problem, because reservations will have quantity one
and it's more likely that a backorder will have a quantity higher than that.

Am I missing something?

Thanks

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Jacques Le Roux]

Hi Paul,

I did not review yet, but by and large you should rather refer to ofbiz-framework

https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/shipment/packing/PackingSession.java#L132

;)

Jacques


Le 04/09/2017 à 08:58, Paul Foxworthy a écrit :

> Hi all,
>
> Please have a look at the code at
> https://github.com/apache/ofbiz/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/shipment/packing/PackingSession.java#L132
>
> I have been testing a situation where there are three serialized items in
> stock, and three on back order. So there are four reservations
> (OrderItemShipGrpInvRes instances), and four inventory items: one for each
> of the serialized items in stock, and one more for the back order.
>
> While packing, the code here is looking for a reservation or reservations
> for the order, in descending order of quantity. So it finds the back order
> reservation first, and proceeds to use it and its associated inventory item
> (with zero QOH and negative ATP) for the shipment, which is stupid.
>
> I think that the code at this point should only look for
> OrderItemShipGrpInvRes instances where the quantity exceeds the
> quantityNotAvailable, and should only allocate to packing the difference
> between the two, and not the full quantity.
>
> I think the problem is not unique to serialized inventory items, but these
> will exacerbate the problem, because reservations will have quantity one
> and it's more likely that a backorder will have a quantity higher than that.
>
> Am I missing something?
>
> Thanks
>
> Paul Foxworthy
>

[Paul Foxworthy]

Thanks Jacques. I did know that :( .

On 4 September 2017 at 18:52, Jacques Le Roux <[hidden email]>
wrote:

> Hi Paul,
>
> I did not review yet, but by and large you should rather refer to
> ofbiz-framework
>
> https://github.com/apache/ofbiz-framework/blob/trunk/applica
> tions/product/src/main/java/org/apache/ofbiz/shipment/
> packing/PackingSession.java#L132
>
> ;)
>
> Jacques
>
>
>
> Le 04/09/2017 à 08:58, Paul Foxworthy a écrit :
>
>> Hi all,
>>
>> Please have a look at the code at
>> https://github.com/apache/ofbiz/blob/trunk/applications/prod
>> uct/src/main/java/org/apache/ofbiz/shipment/packing/Packing
>> Session.java#L132
>>
>> I have been testing a situation where there are three serialized items in
>> stock, and three on back order. So there are four reservations
>> (OrderItemShipGrpInvRes instances), and four inventory items: one for each
>> of the serialized items in stock, and one more for the back order.
>>
>> While packing, the code here is looking for a reservation or reservations
>> for the order, in descending order of quantity. So it finds the back order
>> reservation first, and proceeds to use it and its associated inventory
>> item
>> (with zero QOH and negative ATP) for the shipment, which is stupid.
>>
>> I think that the code at this point should only look for
>> OrderItemShipGrpInvRes instances where the quantity exceeds the
>> quantityNotAvailable, and should only allocate to packing the difference
>> between the two, and not the full quantity.
>>
>> I think the problem is not unique to serialized inventory items, but these
>> will exacerbate the problem, because reservations will have quantity one
>> and it's more likely that a backorder will have a quantity higher than
>> that.
>>
>> Am I missing something?
>>
>> Thanks
>>
>> Paul Foxworthy
>>
>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Paul Foxworthy]

Hi Jacques,

I'm pretty sure there is a problem here. I've created Jira OFBIZ-9677 with
a patch. The patch is fairly simple and has fixed the problem in my tests.

Cheers

Paul

On 4 September 2017 at 19:53, Paul Foxworthy <[hidden email]> wrote:

> Thanks Jacques. I did know that :( .
>
> On 4 September 2017 at 18:52, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Hi Paul,
>>
>> I did not review yet, but by and large you should rather refer to
>> ofbiz-framework
>>
>> https://github.com/apache/ofbiz-framework/blob/trunk/applica
>> tions/product/src/main/java/org/apache/ofbiz/shipment/packin
>> g/PackingSession.java#L132
>>
>> ;)
>>
>> Jacques
>>
>>
>>
>> Le 04/09/2017 à 08:58, Paul Foxworthy a écrit :
>>
>>> Hi all,
>>>
>>> Please have a look at the code at
>>> https://github.com/apache/ofbiz/blob/trunk/applications/prod
>>> uct/src/main/java/org/apache/ofbiz/shipment/packing/PackingS
>>> ession.java#L132
>>>
>>> I have been testing a situation where there are three serialized items in
>>> stock, and three on back order. So there are four reservations
>>> (OrderItemShipGrpInvRes instances), and four inventory items: one for
>>> each
>>> of the serialized items in stock, and one more for the back order.
>>>
>>> While packing, the code here is looking for a reservation or reservations
>>> for the order, in descending order of quantity. So it finds the back
>>> order
>>> reservation first, and proceeds to use it and its associated inventory
>>> item
>>> (with zero QOH and negative ATP) for the shipment, which is stupid.
>>>
>>> I think that the code at this point should only look for
>>> OrderItemShipGrpInvRes instances where the quantity exceeds the
>>> quantityNotAvailable, and should only allocate to packing the difference
>>> between the two, and not the full quantity.
>>>
>>> I think the problem is not unique to serialized inventory items, but
>>> these
>>> will exacerbate the problem, because reservations will have quantity one
>>> and it's more likely that a backorder will have a quantity higher than
>>> that.
>>>
>>> Am I missing something?
>>>
>>> Thanks
>>>
>>> Paul Foxworthy
>>>
>>>
>>
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone] <+61%203%209585%206788>
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]