[
https://issues.apache.org/jira/browse/OFBIZ-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136754#comment-13136754
]
Anil K Patel commented on OFBIZ-4519:
-------------------------------------
Martin,
Can you please check again? Current implementation looks correct.
OrderReadHelper.getOrderItemQuantity() looks like following,
public static BigDecimal getOrderItemQuantity(GenericValue orderItem) {
BigDecimal cancelQty = orderItem.getBigDecimal("cancelQuantity");
BigDecimal orderQty = orderItem.getBigDecimal("quantity");
if (cancelQty == null) cancelQty = ZERO;
if (orderQty == null) orderQty = ZERO;
return orderQty.subtract(cancelQty).setScale(scale, rounding);
}
So what we are getting is Quantity billed and not original quantity, but we
need original order item quantity to do the math in creating invoice process.
Does this sound right or I miss something?
> Order adjustment prorating does not work as expected for when creating an
> invoice for an order with partially canceled items
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: OFBIZ-4519
> URL: https://issues.apache.org/jira/browse/OFBIZ-4519
> Project: OFBiz
> Issue Type: Bug
> Components: order
> Affects Versions: SVN trunk
> Reporter: Martin Kreidenweis
> Attachments: OFBIZ-4519.patch
>
>
> We had a problem with creating invoices for orders with partially canceled
> items (OrderItem.cancelQuantity > 0). The pro-rating of the order adjustments
> doesn't work as expected.
> In the createInvoiceForOrder the billingQuantity passed to the service takes
> into account the cancelQuantity, whereas the quantity from the original order
> item used to prorate the order adjustment amount does not. The attached patch
> changes this by calling OrderReadHelper.getOrderItemQuantity() like done for
> the billItem orderItem, instead of reading the quantity from the original
> orderItem directly.
> I'm not 100% sure this doesn't break anything else. Maybe there was a reason
> not to take the cancelQuantity into account here. It does not break any OFBiz
> tests though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
