Thanks Jacques. I did know that :( . On 4 September 2017 at 18:52, Jacques Le Roux <[email protected]> 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: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: [email protected]
