Changed rounding to 2 decimals to 4 decimals because of rounding errors

[peterjaap]

I would like to propose to change the default rounding decimal to 4 instead of 2. Magento's database supports 4 decimals from way back, but still all calculations are fed through this function where everything is rounded to two decimals.

This is particularly annoying when the products have prices excluding VAT in the catalog, and the price needs to be shown including VAT (which is pretty much always).

Let's say I have a product that costs 0.60 euro excluding VAT. My VAT percentage is 6%. So the including VAT price is 0.6 * 1.06 = 0.636. The problem is; after creating an invoice, the corresponding row 'base_price_incl_tax' (which holds the result of this equation) in sales_flat_invoice_item holds a rounded version of this, namely 0.6400. This doesn't really matter when the quantity is 1, but as soon as the quantities run into the tens, hundreds or even thousands, the differences add up quickly.

Let's say I ordered 1000 of that product, then the difference is (0.64-0.636)*1000 = 4 euro!

[choukalos]

Editted:

@peterjaap -

I'd like to treat your issue as 2 pieces and ask some clarifying questions.

How big is the biz <$5M euro /year, $5-$50M euro/year or > $50M euro /year?
How many regions do you sell into?

1st is pricing including tax for the end customer in which case I'd like to confirm what your end goal is. Is your end goal to have catalog prices loaded excluding tax but then an automated way to display prices including tax for some of your websites?

If so do you expect price including tax to fluctuate based on VAT rate? Ie if France is 20% and Germany is 21% should the 8.00 euro untaxed T-Shirt be 9.68 in Germany and 9.60 in France?

Or do you wish to show 4 digits or precision for unit price?
ie 0.6360 unit price, 1000 qty = 636.00 euro

Otherwise I'd be concerned that buyers would believe there's a math mistake in the cart - i.e. see 0.64 unit price, 1000 qty = 636.00 euro and not the 640.00 euro they expect (or 0.63 unit price, 1000 qty = 636.00 euro and not the 630.00 euro they expect ).

Is the value to you being able to load catalog prices once and have end prices calculated for all the countries you do business in? Is there a need to 'standardize' prices across countries i.e. should France & Germany have the same price for a product if similar VAT rates? Would that apply to all items in the catalog?

For the 2nd piece that's how we store tax data for orders/invoices. I'm currently looking at the EU change of supply law for digital goods and issue #444 to address. Our current thought is by store more details & precision for each item we'd be able to address appropriately. Note as of present there are no plans to display more than 2 digits of precision on orders/invoices but we'd store > 2 digits.

Thanks,
Chuck

[choukalos]

@peterjaap I updated my questions; can you provide your insight? Thanks!

[peterjaap]

Hi Chuck,

To answer all your questions; yes. And by that I mean; we build a lot of webshops for a lot of customers and they all have different wishes. So flexibility is key.

Storing 4 decimals (and not rounding to 4) is fine. But then I would like to see the 4 digits represented in the backend. For example, to see features that are added by ET_Currencymanager (http://www.magentocommerce.com/magento-connect/et-currency-manager.html) to Magento2.

And also show 4 decimals for bundled prices (data.selection_price_value = Number(data.selection_price_value).toFixed(4); instead of toFixed(2) in the file app/design/adminhtml/default/default/template/bundle/product/edit/bundle/option/selection.phtml).

[maksek]

Hi @peterjaap, rounding was extracted from app/code/Magento/Store/Model/Store.php, the PR can't be merged. Please update it with latest codebase, and resubmit if it is till actual. Thanks.

[maksek]

Resolution: reject. Reason: inactivity from creator for 2 weeks, failed builds, wrong branch, outdated codebase.

[peterjaap]

Will revisit this when I have more time do dive into M2. I feel like this might still be an issue.