Add rounding and currency decimal place options

[lukeholder]

Currently, the price of a product is rounded to the decimal places of the base currency, when the product is on a line item in an order/cart.

This provides consistency with summing and discount/tax calculations.

Some stores want to store products in more decimal places than the currency provides. We should look to support this, but need to consider how the order will continue to sum correctly - and have percentage-based taxes and discounts also take these options into account.

Please add your voice here with your use-cases.

[mofman]

We're in the process of building an order system for a company who supplies Home Heating Oil. The price per litre of the oil is often delimited by fractions of pence eg. £0.495. At the moment Craft will round this up to £0.50.

[mofman]

In order for us to ship this site I've had to find a work arround. What I've ended up doing is instructing the admin to multiply their prices by 10 (they only have one product - heating oil). The means rather than entering £0.495 they enter £4.95.

Then I have created an adjuster which discounts this subtotal by 90% which gives us the correct total.

Really this is less than ideal as their backend shows crazy high numbers with huge discounts.

    $adjustments = [];

    foreach ($order->getLineItems() as $item) {
        $adjustment = new OrderAdjustment;
        $adjustment->type = 'discount';
        $adjustment->name = 'Decimal fixer';
        $adjustment->description = 'Decimal fixer';
        $adjustment->sourceSnapshot = [ 'data' => 'value' ];
        
        $originalTotal = $item->price * $item->qty;
        $discountTotal  = ($originalTotal / 100) * 90;

        $adjustment->amount = -$discountTotal;
        $adjustment->setOrder($order);
        $adjustment->setLineItem($item);

        $adjustments[] = $adjustment;
    }

    return $adjustments;

[aladrach]

+1 here. Commerce 3.1 has broken my calculations for partial quantities, due to the changed rounding strategy. We have a client who wants to sell fabric by the half yard. So I wrote some logic so that they inventory by the number of half yards, and we do the conversion on the front end. However, say they want to sell it at $4.99 a yard, which is divided in half for a per half yard cost of $2.495. Commerce 3.1 now rounds that up to 5.00 per yard since it rounds before the quantity calculation

[elivz]

Another related use-case:

We are integrating with an external ERP system that uses "bankers rounding" (rounding halves to the nearest even number, the default in .NET). When calculating percentage-based price modifiers (discounts, taxes, etc) this can lead to 1-cent discrepancies in some cases.

From what I can see, it looks like that is entirely controlled by one line of code in the CurrencyHelper. What would be great is if either the mode parameter could be made configurable in the Commerce config file, or if it were possible to override that class with one of our own somehow. Then we could set to the mode to PHP_ROUND_HALF_EVEN (or any of the other options) and make things match.

[xsinisa]

@nfourtythree I have similar rounding issue, as the amounts are added in 3 decimals and rounding is done before the tax calculation. Do you have any info when the option to set rounding method will be done? Do you have any idea for a workaround?

[peteeveleigh]

Similar issue for me with one of my ceramic tile sites.

Products are priced by 100 in the client's inventory system but sold by the single tile. Customers may purchase any number of tiles.

For example, product is price at £999.40 per 100. This product is imported into Commerce and the price set at £9.994 each

Customer puts 100 tiles in their cart. Commerce rounds the unit price to 2 decimals (£9.99) before applying the quantity multiplication. So we end up with 100 tiles costing £999 instead of £999.40.

I know there have been many discussions about rounding during Commerce's development but I strongly believe that no rounding should be done at all. Let us do that when outputting prices by means of the currency filter (or whatever necessary).

There's a further UI issue that I notice. When entering a price with 4 decimal places in the product edit form of the CP, it is rounded to 3 decimal places, even though the underlying value has 4. Given we are inputting the 4 decimals for a reason it seems like this is unnecessary and contributes to, or creates new issues.

[russback]

I found an issue related to this with the Square API.

The round() method Commerce uses for its Tax adjuster rounds up, but I found that an issue here in that when creating an order in the Square API, they round down.

Example:

• Tax rate 3.4%
• Base price 342.50
• Calculation by Commerce = rounded up to 11.65
• Calculation by Square = rounded down to 11.64

So we create an order in Square and use a custom payment gateway to take payment, but as the tax is out by 1 cent, the payment fails.

I looked at overriding the core Tax adjuster class but the methods that call the rounding function are private. Duplicating the entire Tax adjuster ad replacing it in a module (and updating the references to rounding) does work, but obviously that's not ideal.

Another workaround is to create a custome adjuster that alters the total order amount to bring the discrepancy into line, but again, not ideal.

[joshuapease]

I work with a client that has need of this functionality. They sell small metal components in large quantities (tens of thousands to millions). Some of their parts are priced at three or more decimal places (0.125 for example).

At those quantities, rounding can introduce a sizable price increase/decrease.

They are comfortable with rounding to 2 decimal places when the Line Item's subtotal is calculated.

salePrice just need to be an arbitrary decimal point.

Looking at the discount & tax code I see that they reference salePrice, so I could see the potential for rounding weirdness.

Do some of the Craft 5 currency changes get us any closer in this direction? I know there talk of using ints/cents and/or the money/money package. Does that make this type of thing harder?

[abm-schuh]

We have the exact same issue here. We have prices with more decimal points. The subtotal should be calculated from all decimal points.

[lukeholder]

Thanks for the updates everyone.

This is something that is on our list but not supper high priority to implement (more decimal places). This is especially true now that we are using the Money library and Teller service to do accurate calculate arithmetic and move away from floats.

We could look to support more decimal places in qty if the stock/inventory system is not used for the product.

Moving this to a discussion and out of issues since it isnt a bug but a feature request. Any bugs related to calculations or rounding please submit them as new issues. Thanks.