[
https://issues.apache.org/jira/browse/OFBIZ-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502870
]
Ray Barlow commented on OFBIZ-1070:
-----------------------------------
Jacopo,
That looks like it would be safer. Having only read through the patch I would
like to test the packing list against the scenario of an order with the same
productId occurring on more than one line item, specifically to check if it
collates the productId on the packing list.
OK I just quickly raised a test order on the demo server and it did collate the
productId items on to the same line on the packing list. If that is the desire
for the packing list to collate then I can imagine a scenario where by if I do
a split/multiple shipment for an order and each shipment contains one of the
products in question I'm thinking with your patch applied we will get a short
count on the requested? But I need some time to apply your patch locally and
test that a little further...
Thanks,
Ray
> Packing PDF calculates wrong value for requested count with when handling
> multiple issuances
> --------------------------------------------------------------------------------------------
>
> Key: OFBIZ-1070
> URL: https://issues.apache.org/jira/browse/OFBIZ-1070
> Project: OFBiz
> Issue Type: Bug
> Components: product
> Affects Versions: SVN trunk
> Environment: N/A
> Reporter: Ray Barlow
> Attachments: packslip.patch
>
>
> If the data hangs around on the test site see order : WSCO10000 The original
> quantity requested was 18 for "GZ-8544 - Big Gizmo" and the packing slip
> shows 36 requested and 18 shipped.
> To reproduce this you just need to create an order with a product that will
> be allocated against more than one inventory issuance. For the WSCO10000 test
> order the total QOH on the product before ordering was 18 split across two
> inventory items one with 15 and one with 3, so I asked for a quantity 18 in
> the order and then once created just approved and quick shipped the whole
> order. View the packing slip PDF and you can see the problem.
> This is the problem code segment : PackingSlip.bsh line 49
> ......
> // next scan the order items (via issuances) to count the quantity of each
> product requested
> quantityRequestedByProduct = FastMap.newInstance();
> issuances = shipment.getRelated("ItemIssuance");
> for (iter = issuances.iterator(); iter.hasNext(); ) {
> issuance = iter.next();
> orderItem = issuance.getRelatedOne("OrderItem");
> productId = orderItem.get("productId");
> requested = quantityRequestedByProduct.get(productId);
> if (requested == null) requested = new Double(0);
> cancelQuantity = orderItem.getDouble("cancelQuantity");
> quantity = orderItem.getDouble("quantity");
> requested += quantity.doubleValue() - (cancelQuantity != null ?
> cancelQuantity.doubleValue() : 0);
> quantityRequestedByProduct.put(productId, requested);
> }
> ......
> I can suggest a fix easily enough: (formatting aside!)
> ...
> requested = quantityRequestedByProduct.get(productId);
> if (requested == null) {
> requested = new Double(0);
> cancelQuantity = orderItem.getDouble("cancelQuantity");
> quantity = orderItem.getDouble("quantity");
> requested += quantity.doubleValue() - (cancelQuantity != null ?
> cancelQuantity.doubleValue() : 0);
> quantityRequestedByProduct.put(productId, requested);
> }
> ...
> basically wrap the code block after the if in to the whole condition as I
> can't see a reason you'd want to recount the same product.
> I'd appreciate comment for side effects because it looks like whoever coded
> it in the first place kind of expected the productId to appear more than once
> otherwise why call "get"? Is the above fix OK or is there another scenario
> I'm not thinking of?
> Ray
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
