prices in product node edit files have 3 decimal places

This was done to allow modules that control the price of products more accuracy when multiplying percentages. European stores, for example, have to display the price with the VAT included, and without 3 decimal places, they can't always set the price to the exact amount they want.

Use uc_currency_format() or possibly number_format() when displaying prices.

And how can this be fixed in the node edit form... ?

I just found out in development on another module that if you use PHP's round(), it will strip off trailing 0's. So, in places like the product edit form, why don't we just apply round() to the default value of textfields to the maximum number of decimal places? Then instead of 13.820 you'd see 13.82.

Tagging.

Rounding would throw off all of the prices that actually need to be stored with three decimal places.

I'm not sure why. There's a setting in the store format settings where you can specify "Number of decimal places." Perhaps we just need to enhance / use that field, but if it's configurable then someone who needs 3 decimal places on a node form could adjust that when they setup their currency format. It doesn't have to affect any storage or any other fields... perhaps it could be split up into number of places for display and a separate for data entry. Make sense?

+1 (for my shop I would set "Number of decimal places for display" = 2 and "Number of decimal places for data entry" = 5)

was just thinking about this again... in case you want to make this configurable I would even go a step further:
in order to reduce future support requests it should have a good setting out of the box which will not produce rounding errors (i.e. 5 decimal places in the database) but not confuse administrators unnecessarily (only show them 2 decimal places by default).

therefor I now see the following settings:
"Number of decimal places for display in the shop" (default = 2, range = 0-3 [3 is a potential solution to the rounding problem in countries with 20% VAT rate such as Austria and others])
"Number of decimal places for display to the admin" (default = 2, range = 0-6 [admin should be able to edit the full precision of prices in the db])
"Number of decimal places for database" (default = 5, range = 0-6 (6 solves a special case for the reduced VAT rate in France)

the last setting could actually be hardcoded to 5 (or even 6, but that case is really rare).

This is related to #479784: Order rounding.

Deciding how many decimal places are actually stored is mostly up to the database. I think that decision is for #479784 like Ryan said. This issue is about how many are displayed on the node edit form, which is only somewhat related to the number of decimal places displayed everywhere else on the site.

Patch removes any trailing zeros down to the last two decimal places. It considers 6 decimal places to be the "exact" value that was entered, since it sounds like that's the most any monetary application ever needs.

Nice solution. It works for me as expected when I disable the VAT module.

Question: can we use the same formating rules for "Cost" & "Price" on the edit options page?
EDIT: and maybe also when displaying the default on edit attributes? re-EDIT: on second thought it probably doesn't make sense for the default values, as the customer also only will see 2 digits.

Yeah, that makes sense to do the same thing for attributes. New patch includes those changes.

It looks good from here as well, so it's committed. Thanks for the review.