In the case we add a percent discount which causes rounding to occur on the line item the amounts of the line items being added up and the order can be made to not match up. This is because the discount price component is being added with the un-rounded amount which is then aggregated for the order total.

An Example: Create a 50% off discount for product A which has a price of 4.99 and then add 2 of product A to your cart. You will see the unit price of the line item showing as $2.50, the total line item price showing as $5 and the order total showing as $4.99.

Attached is the simple patch to use the rounded amount for the discount price component.

Comments

nchar’s picture

Status: Active » Needs review
StatusFileSize
new945 bytes

This mismatch issue is not fixed yet and the above patch does not work at the latest commerce_discount release.

The problem if I get it right is that the amount of the discount component gets rounded:

$difference = array(
    'amount' => commerce_round(COMMERCE_ROUND_HALF_UP, $discount_amount['amount']),
    'currency_code' => $discount_amount['currency_code'],
    'data' => array(
      'discount_name' => $discount_name,
      'discount_component_title' => empty($component_title) ? 'discount' : $component_title,
    ),
  );

while the price amount is calculated without the discount amout to be rounded first. This causes a mismatch of some cents.
$updated_amount = commerce_round(COMMERCE_ROUND_HALF_UP, $current_amount + $discount_amount['amount']);

The following patch solves the issue by adding the rounding of the discount amount before everything else.

ASupinski’s picture

I am missing the change in your patch from mine?

hmartens’s picture

StatusFileSize
new24.49 KB

Thanks guys for working on this. My client just emailed me saying that her one order is out by $0.01 on the one order and asked me what's happening.

Is there anyway we can manually set it somewhere on how to work with rounding off the amount? I've attached a screenshot of the discount behaviour that we're seeing.

Thank you.

torgospizza’s picture

Version: 7.x-1.0-alpha3 » 7.x-1.x-dev
Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

The patch in #1 works for me.

It solved an issue we were having with Commerce Coupon/Discounts and PayPal. Discounts rounded up to the nearest cent in some cases, causing the ITEMAMT to be one cent less than the L_ITEMAMT for that particular line item. (It only occurred with % discounts for products.)

I'd say we should get this committed, as it's extremely important and the bug causes havoc when attempting to use Percentage off Discounts (with Coupons) and PayPal.

torgospizza’s picture

Priority: Major » Critical

Setting to critical. I'm actually surprised more people are not seeing this bug.

tnfno’s picture

I think this bug is very common, but you do not realize it is there until you discover that customers cannot checkout with Paypal and the only error they get is a message that something is wrong on the review page.

I believe this is not only an issue with discount, but also other modules like multicurrency that alters the unit price. They all suffer since the total amount does not add up if you have multiple items.

Lots of lost sales here so I agree, this is critical.

joelpittet’s picture

RTBC++

torgospizza’s picture

There is a duplicate issue at #2468943: Ensure proper rounding of price amounts and components when components are added via discounts but I'm not sure which one handles this issue the best. Would love a consensus!

joelpittet’s picture

@torgosPizza actually it's hard to decide :S one removes the rounding (which won't get stored) and this just rounds it twice in the updated amount.

deggertsen’s picture

Priority: Critical » Normal
Status: Reviewed & tested by the community » Postponed

Is there a reason the rounding is needed? I personally would say there should be no rounding or give the option of rounding down, rounding up, or no rounding. If you don't give these options then people with similar problems mentioned in #2468943: Ensure proper rounding of price amounts and components when components are added via discounts will continue to have issues.

So for a short term fix I recommend the patch in #2468943: Ensure proper rounding of price amounts and components when components are added via discounts be committed right away, but for a real fix I think we should allow options. Changing status of this issue to match my recommendation and marking other issue as RTBC. Once that patch is applied we can change the status of this issue to "needs work" and create a patch to give the options. If we decide that no rounding is needed, then we could simply close this issue as a duplicate of #2468943: Ensure proper rounding of price amounts and components when components are added via discounts.

tnfno’s picture

I agree that rounding may not be needed for this module and I am not sure where this problems should be fixed, it is probably a 'core' shopping cart issue.

As mentioned are my problem also with the multicurrency module. The problem I get is that the price are stored with 8(!) decimals in the line item, but rounded to 2 decimals when you get the total for multiple items. So if you have a product that costs 130,72 and buy 6x the total price is shown as 784,33

130,72 x 6 should be 784,32 BUT it is being calculated to 784,33 since the actual price in the line item used for the calculation is 13072.23442218 (/100 = 130.7223442218) after the currency conversion (and % discount?) are calculated. This is what happens with the multicurrency module and the problem is probably the same with discounts.

If you try to checkout this cart with Paypal for example, you will get an error in your review page that something is wrong in the form, but if you examine the Paypal log you will realize that Paypal rejects the transaction since the order lines and total amount does not add up. The total of the items must match exactly the total amount so if you send order lines with 6x 130,72 and a total amount of 784,33 you will not get paid, it has to be 100% correct.

https://www.drupal.org/node/2466941

torgospizza’s picture

@tnfno, if you are getting a rounding error when using a % discount you should definitely check the patch in #2468943: Ensure proper rounding of price amounts and components when components are added via discounts. I don't believe it's a core Cart bug, but related to Discounts. Unless you also see this type of error without a discount, in which case your assumption might be correct.

joelpittet’s picture

Status: Postponed » Postponed (maintainer needs more info)
torgospizza’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)