[jira] Created: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
Locked
[jira] Created: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
 
|
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 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. |
[jira] Updated: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
|
|
[ https://issues.apache.org/jira/browse/OFBIZ-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato updated OFBIZ-1070: ------------------------------------- Attachment: packslip.patch Ray, what do you think of the attached (untested) patch? This will also handle the situation where the same product is in different order items. Does it make sense? > 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. |
[jira] Commented: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
|
|
In reply to this post by Nicolas Malin (Jira)
[ 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. |
[jira] Updated: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Barlow updated OFBIZ-1070: ------------------------------ Attachment: packslip.patch Got around to testing it and found a few more issues. It might have been my misunderstanding of the column "Total Shipped" but I expected it to display the total of all shipped product items including previous shipments. But it was only displaying the total of this particular shipment which would only be a different value if you split the same product into more than one package in a shipment. I've now changed it to display another column "In this shipment" only if there is more than 1 package in the shipment and it shows the totals of the products within the shipment. The "Total Shipped" column now displays the quantity of this shipment plus earlier shipments if any. Also to get the requested count to be correct when one product code is on multiple order lines and is then split across multiple packages and shipments I had to change the look up of issuances to be against the order rather than just the shipment otherwise it wouldn't count all the requests. I've looked at this in quite a few scenarios and it looks OK to me now so any comments welcome before I commit it shortly. Ray PS: Found more problems with requested counts on the packing page but I'll create a new Jira for that. > 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, 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. |
[jira] Closed: (OFBIZ-1070) Packing PDF calculates wrong value for requested count with when handling multiple issuances
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Barlow closed OFBIZ-1070. ----------------------------- Resolution: Fixed Fix Version/s: SVN trunk Committed rev: 552809 > 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 > Fix For: SVN trunk > > Attachments: packslip.patch, 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. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |