Update app/code/core/Mage/Adminhtml/Block/Catalog/Product/Helper/Form/Pr... #234
Conversation
…/Price.php Recently had an issue where the price of a product had 3 decimal points on the DB, 10.245 for example, but showed the rounded to 2 decimals price (10.25) on the admin panel product edit page. When hitting save for that product from the admin panel, it would save the escaped value with 2 decimal points, replacing 10.245 with 10.25, which is completely undesirable and results in all kind of funny prices after taxes are applied. Possible fixes: (1) Allow more decimal points. 4 seems reasonable, but the issue might persist. (2) Simply return $value as it comes from the database, since the method already checks that is a numeric value. Note: the other reason why the number_format was being done is to remove the thousand comma separator, but is_numeric(1,230) is false, so price data coming from the DB with comma thousand separators won't be valid anyway.
|
Hello. In which currency/market you saw prices with 3 or 4 decimal places? |
|
Hi, I had once a customer, who sold balloons. The unit prices were indeed with four decimal places. So at that time, I had to make sure that four decimal places could be entered through the backend. Best regards, |
|
The issue comes because prices for products are managed from a different system, and imported automatically into Magento with several decimal places. For example, a price might be imported as 17.355, which on market with 21% tax, like the Netherlands, should result in 17.355_1.21 = 20.99955, rounded up to _21.00* on the product view page. |
|
Hello. We will look into it but the solution requires reviewing all of the pricing logic. This is on our roadmap however no in the short term. |
|
Hi Artus - what country is the ballon example from? Did that merchant show customer prices with 4 decimal places? I'm the Magento product manager responsible for the tax module and would welcome any questions, comments, suggestions or help to improve our tax engine. Regards, |
|
Hi Chuck, I only used the Netherlands as an example. In the study case I described, the price is shown to the customer with 2 decimal points, but a rather minimal change in the amount saved in the DB, the price shown changes from 21.00 to 21.01, which is of course very undesirable. The method in which I proposed the fix only seems to be used for the shown value in the admin panel, for styling purposes (correct me if I'm wrong) since I don't see a reason why the price of a product should be forcefully limited to 2 decimal points on the admin panel, specially when we are talking about prices before taxes. (Please note that this issue means Magento is applying a round to 2 decimal values, and it's effectively and unintentionally enforcing the change on the DB without notification to the user.) |
|
Hi Chuck, the example comes from Germany. The merchant showed their customers prices with two decimal places and have sold per hundred. But calculated was internal with four decimal places on a single balloon, the alternative was, to change the units from one to hundred. But there were reasons why we couldn't do this. I guess this had something to do with configurable products (balloon prints) and their price calculation. Best Regards, |
|
I thought it was desirable for European merchant's to load their catalog prices including tax (I believe in all the countries mentioned prices are shown including tax)? Doesn't this most likely mean they had to do a fair bit of manual effort to load their prices without tax? Allowing pricing to be loaded with more than 2 digits of precision, but only showing a customer 2 digits of precision will create cart abandonment scenarios with out some further logic/etc. Example case (for abandonment): Buy 37 balloons Customer expects 21.00 * 37 should be 777.00 - off by 0.02 -Chuck |
|
Hi Chuck, One can argue that happens with two decimal points as well: Mathematically, we can only get more precision by allowing more decimal points to be used. For example, if we allow the use of 4 decimal points. and with the 37 balloons example: Since more decimal points allow much better precision in prices, and more flexibility in the use of the price calculation process, I don't see a reason to force the use of 2 decimal points. Specially when it's not really forced in the database or Magento itself, since it will allow users to save the price with as many decimal points as wanted, but will escape the value when showing it on the admin panel, and round it to 2 decimal points. |
|
Hi Chuck,
Yes, for Germany (B2C) this is typically, and for the grand total the customer expects net and gross prices as well as the taxes separately.
This is hard to be generalized. It depends on the merchant or producer, but mostly they use gross prices.
Well here is the funny thing in this case, the price per ballon were e.g. 0.0604 €. The selling units were mostly 100 ballons, but if we had used this as a products base price (6.04 €), it had made the whole catalog more difficult to handle. Best regards, |
|
Hello cdquirozc, |
MQE-1057: Update metadata filenames convention
...ice.php
Recently had an issue where the price of a product had 3 decimal points on the DB, 10.245 for example, but showed the rounded to 2 decimals price (10.25) on the admin panel product edit page.
When hitting save for that product from the admin panel, it would save the escaped value with 2 decimal points, replacing 10.245 with 10.25, which is completely undesirable and results in all kind of funny prices after taxes are applied.
Possible fixes:
(1) Allow more decimal points. 4 seems reasonable, but the issue might persist.
(2) Simply return $value as it comes from the database, since the method already checks that is a numeric value.
Note: the other reason why the number_format was being done is to remove the thousand comma separator, but is_numeric('1,235') is false, so price data coming from the DB with comma thousand separators won't be valid anyway.